RE: Fwd: Re: adding second zone

[Darcy Kevin (FCA)]

Are you sure that's what you want? In a different thread, you said you had a 
second LAN besides 192.168.1.0/24; you called it "LAN2", and further described 
it as being "DHCP only". That second LAN was identified by you as 
192.168.10.0/24.

I'm thinking you meant to define the second zone as 10.168.192.in-addr.arpa, 
but you mistyped it as 1.168.192.in-addr.arpa, and thus caused a conflict with 
an already-existing zone.


- Kevin

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Pol 
Hallen
Sent: Friday, September 23, 2016 3:52 AM
To: bind-users@lists.isc.org
Subject: Re: Fwd: Re: adding second zone

2 zone on same network (192.168.1.0/24)

thanks

>> 1.168.192.in-addr.arpa is on primary zone, if I add second zone I've 
>> this error
>
> you apparently have 1.168.192.in-addr.arpa defined two times what are 
> you trying to do?
>


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

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

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

R: Minimal responses and speeding up queries

[Job]

Hi Tony,

excellent answer, thank you very much.
My first goal, since i use Bind 9.10 in conjunction with DLZ (old driver), is 
limiting additional queries to reduc load into backend database system.
By tuning the minimal-responses i have few database queries less than before; 
it is a good step, to begin.

I will try different parameters and configurations in order to limit, at 
possible, the number of additional queries!

Thank you, Cheers from Italy!

Francesco


Da: bind-users [bind-users-boun...@lists.isc.org] per conto di Tony Finch 
[d...@dotat.at]
Inviato: venerdì 23 settembre 2016 13.21
A: Reindl Harald
Cc: bind-users@lists.isc.org
Oggetto: Re: Minimal responses and speeding up queries

Reindl Harald  wrote:
>
> just because without additional responses are part of the inital question and
> may save asking for that information - in case the additional info is not
> needed by the client it saves traffic

There are a few situations in which additional data is useful in theory,
but it's surprisingly poorly used in practice.

End-user clients are generally looking up address records, and the
additional and authority records aren't of any use to them.

For MX and SRV records, additional data can reduce the need for extra A
and  records - but only if both A and  are present in the
response. If either RRset is missing the client still has to make another
query to find out if it doesn't exist or wouldn't fit. Some code I am
familiar with ignores additional sections in MX responses and always does
separate A and  lookups, because it's simpler.

The other important case is for queries from recursive servers to
authoritative servers, where you might hope that the recursive server
would cache the additional data to avoid queries to the authoritative
servers.

However, in practice BIND is not very good at this. For example,
let's query for an MX record, then the address of one of the MX target
hosts. We expect to get the address in the response to the first query, so
the second query doesn't need another round trip to the authority.

Here's some log, heavily pruned for relevance.

2016-09-23.10:55:13.316 queries: info: client @0x7f9d380311b0 ::1#55658 
(isc.org): view rec: query: isc.org IN MX +E(0)K (::1)
2016-09-23.10:55:13.318 resolver: debug 11: sending packet to 2001:500:60::30#53
;; QUESTION SECTION:
;isc.org.   IN  MX
2016-09-23.10:55:13.330 resolver: debug 10: received packet from 
2001:500:60::30#53
;; ANSWER SECTION:
;isc.org.   7200IN  MX  10 mx.pao1.isc.org.
;isc.org.   7200IN  MX  20 mx.ams1.isc.org.
;; ADDITIONAL SECTION:
;mx.pao1.isc.org.   3600IN  A   149.20.64.53
;mx.pao1.isc.org.   3600IN  2001:4f8:0:2::2b
2016-09-23.10:56:13.150 queries: info: client @0x7f9d300609e0 ::1#49485 
(mx.pao1.isc.org): view rec: query: mx.pao1.isc.org IN A +E(0)K (::1)
2016-09-23.10:56:13.151 resolver: debug 11: sending packet to 2001:500:60::30#53
;; QUESTION SECTION:
;mx.pao1.isc.org.   IN  A

Hmf, well that's disappointing.

Now, there's a rule in RFC 2181 about ranking the trustworthiness of data:

5.4.1. Ranking data

   [ snip ]

   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query.  They may be returned as additional
   information where appropriate.  Ignoring this would allow the
   trustworthiness of relatively untrustworthy data to be increased
   without cause or excuse.

Since my recursive server is validating, and isc.org is signed, it should
be able to authenticate the MX target address from the MX response, and
promote its trustworthiness, instead of making another query. But BIND
doesn't do that.

There are other situations where BIND fails to make good use of all the
records in a response, e.g. when you get a referral for a signed zone, the
response includes the DS records as well as the NS records. But BIND
doesn't cache the DS records properly, so when it comes to validate the
answer, it re-fetches them.

Tony.
--
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Northwest Fitzroy, West Sole: Southerly, veering westerly later, 6 to gale 8.
Rough or very rough. Fair then rain. Good, occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

bind-users mailing list

Re: root.hind or named.hint file update

[/dev/rob0]

On Fri, Sep 23, 2016 at 02:31:51PM +0200,
   Matus UHLAR - fantomas wrote:
> >Pol Hallen wrote:
> >>
> >>is it recommend put a cron script for auto-update root.hind
> >>and named.hint db?
> 
> On 23.09.16 12:54, Tony Finch wrote:
> >No, it's best not to have a hints file and just use the one
> >built in to BIND.

I agree.

> i would not say that... it's better to use builtin hints file 
> than having outdated hints file.
> 
> But if someone does care about hints file, it's better to have 
> current version, when the builtin one is older.

Seem that all of Pol's posts lately are about trying to fix problems 
which do not exist, and this one is solidly there.

The fact is, outdated hints (whatever the source, built-in or from 
hints file) will not yet cause a problem.  You could look back to the 
1990s, find a hint file from then, use that now, and you WILL find 
active root servers.

Once you find the root, the hints file is no longer used.  When your 
cached root NS RRset expires, named will go to the known root servers 
to refresh that NS RRset.

In theory, someone could put up a counterfeit root nameserver on an 
IP address formerly used by a real root server, but in practice I 
doubt this will happen.  Furthermore, DNSSEC validation defeats an 
attack of that nature.

Pol, if you are interested in knowing how named uses hints, there's
a fairly recent article on the ISC KB which goes into detail.[1]  My 
personal recommendation, however, is that if you wish to learn more 
about how DNS works, consult a book such as the Cricket book.


[1] Sorry, I am too lazy this morning to look it up for you.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: root.hind or named.hint file update

[Matus UHLAR - fantomas]

Pol Hallen  wrote:


is it recommend put a cron script for auto-update root.hind and named.hint db?


On 23.09.16 12:54, Tony Finch wrote:

No, it's best not to have a hints file and just use the one built in to BIND.


i would not say that... it's better to use builtin hints file than having
outdated hints file.

But if someone does care about hints file, it's better to have current
version, when the builtin one is older.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Have you got anything without Spam in it?
- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: root.hind or named.hint file update

[Tony Finch]

Pol Hallen  wrote:
>
> is it recommend put a cron script for auto-update root.hind and named.hint db?

No, it's best not to have a hints file and just use the one built in to BIND.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Southeast Fitzroy: Southerly 4 or 5, increasing 6 to gale 8. Moderate or
rough, occasionally very rough later. Rain later. Good, becoming poor later.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

root.hind or named.hint file update

[Pol Hallen]

Hello all :-)

is it recommend put a cron script for auto-update root.hind and 
named.hint db?


wget --user=ftp --password=ftp ftp://ftp.rs.internic.net/domain/db.cache 
-O /etc/bind/db.root

dig +bufsize=1200 +norec NS . @a.root-servers.net > /var/named/named.root

using debian there isn't any cron script

thanks!

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

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

Re: Minimal responses and speeding up queries

[Tony Finch]

Reindl Harald  wrote:
>
> just because without additional responses are part of the inital question and
> may save asking for that information - in case the additional info is not
> needed by the client it saves traffic

There are a few situations in which additional data is useful in theory,
but it's surprisingly poorly used in practice.

End-user clients are generally looking up address records, and the
additional and authority records aren't of any use to them.

For MX and SRV records, additional data can reduce the need for extra A
and  records - but only if both A and  are present in the
response. If either RRset is missing the client still has to make another
query to find out if it doesn't exist or wouldn't fit. Some code I am
familiar with ignores additional sections in MX responses and always does
separate A and  lookups, because it's simpler.

The other important case is for queries from recursive servers to
authoritative servers, where you might hope that the recursive server
would cache the additional data to avoid queries to the authoritative
servers.

However, in practice BIND is not very good at this. For example,
let's query for an MX record, then the address of one of the MX target
hosts. We expect to get the address in the response to the first query, so
the second query doesn't need another round trip to the authority.

Here's some log, heavily pruned for relevance.

2016-09-23.10:55:13.316 queries: info: client @0x7f9d380311b0 ::1#55658 
(isc.org): view rec: query: isc.org IN MX +E(0)K (::1)
2016-09-23.10:55:13.318 resolver: debug 11: sending packet to 2001:500:60::30#53
;; QUESTION SECTION:
;isc.org.   IN  MX
2016-09-23.10:55:13.330 resolver: debug 10: received packet from 
2001:500:60::30#53
;; ANSWER SECTION:
;isc.org.   7200IN  MX  10 mx.pao1.isc.org.
;isc.org.   7200IN  MX  20 mx.ams1.isc.org.
;; ADDITIONAL SECTION:
;mx.pao1.isc.org.   3600IN  A   149.20.64.53
;mx.pao1.isc.org.   3600IN  2001:4f8:0:2::2b
2016-09-23.10:56:13.150 queries: info: client @0x7f9d300609e0 ::1#49485 
(mx.pao1.isc.org): view rec: query: mx.pao1.isc.org IN A +E(0)K (::1)
2016-09-23.10:56:13.151 resolver: debug 11: sending packet to 2001:500:60::30#53
;; QUESTION SECTION:
;mx.pao1.isc.org.   IN  A

Hmf, well that's disappointing.

Now, there's a rule in RFC 2181 about ranking the trustworthiness of data:

5.4.1. Ranking data

   [ snip ]

   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query.  They may be returned as additional
   information where appropriate.  Ignoring this would allow the
   trustworthiness of relatively untrustworthy data to be increased
   without cause or excuse.

Since my recursive server is validating, and isc.org is signed, it should
be able to authenticate the MX target address from the MX response, and
promote its trustworthiness, instead of making another query. But BIND
doesn't do that.

There are other situations where BIND fails to make good use of all the
records in a response, e.g. when you get a referral for a signed zone, the
response includes the DS records as well as the NS records. But BIND
doesn't cache the DS records properly, so when it comes to validate the
answer, it re-fetches them.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Northwest Fitzroy, West Sole: Southerly, veering westerly later, 6 to gale 8.
Rough or very rough. Fair then rain. Good, occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: adding second zone

[Mark Andrews]

In message <037ba6b1-fa12-945c-e9ac-e2a99d713...@thelounge.net>, Reindl Harald 
writes:
> 
> 
> Am 23.09.2016 um 09:52 schrieb Pol Hallen:
> > 2 zone on same network (192.168.1.0/24)
> 
> you can't have two ptr-zones for the same ip-block and the reasons are 
> very obvious - what should the naswer be? from zone 1, zone 2, both, mixed?
> 
> >>> 1.168.192.in-addr.arpa is on primary zone, if I add second zone I've
> >>> this error
> >>
> >> you apparently have 1.168.192.in-addr.arpa defined two times
> >> what are you trying to do?

I suspect there is a tool being used to build forward and reverse
zones from a common source.  This is being done for two zones both
using the same /24 for addresses resulting in two instances of the
reverse zone.  The contents of these zones need to be merged outside
of named, not inside named.


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: adding second zone

[Reindl Harald]

Am 23.09.2016 um 09:52 schrieb Pol Hallen:

2 zone on same network (192.168.1.0/24)


you can't have two ptr-zones for the same ip-block and the reasons are 
very obvious - what should the naswer be? from zone 1, zone 2, both, mixed?



1.168.192.in-addr.arpa is on primary zone, if I add second zone I've
this error


you apparently have 1.168.192.in-addr.arpa defined two times
what are you trying to do?

___
Please visit https://lists.isc.org/mailman/listinfo/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: Fwd: Re: adding second zone

[Pol Hallen]

2 zone on same network (192.168.1.0/24)

thanks


1.168.192.in-addr.arpa is on primary zone, if I add second zone I've
this error


you apparently have 1.168.192.in-addr.arpa defined two times
what are you trying to do?




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

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

Re: R: Minimal responses and speeding up queries

[Matus UHLAR - fantomas]

On 23.09.16 09:33, Job wrote:

Very interesting answers, thank you first of all.

Regarding:

BIND 9.11 adds two more stops on the knob


There will be an option to add these stops or, by default, bind-9.11 will care 
about this?


care about what?
DNS client will fetch data it needs to resolve a query.

If you turn mimimal-responses on, the required data may not be in the
answer. That will result into another query send, which means number of
queries increases.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Posli tento mail 100 svojim znamim - nech vidia aky si idiot
Send this email to 100 your friends - let them see what an idiot you are
___
Please visit https://lists.isc.org/mailman/listinfo/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: Fwd: Re: adding second zone

[Matus UHLAR - fantomas]

On 23.09.16 09:31, Pol Hallen wrote:
Sep 22 21:27:12 asia.bunker.org named[6079]: 
/etc/bind/named.conf.local:32: zone '1.168.192.in-addr.arpa': already 
exists previous definition: /etc/bind/named.conf.local:17

Sep 22 21:27:12 asia.bunker.org named[6079]: loading configuration: failure

1.168.192.in-addr.arpa is on primary zone, if I add second zone I've 
this error


you apparently have 1.168.192.in-addr.arpa defined two times
what are you trying to do?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
   One OS to rule them all, One OS to find them, 
One OS to bring them all and into darkness bind them 
___

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

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

R: Minimal responses and speeding up queries

[Job]

Very interesting answers, thank you first of all.

Regarding:
>>BIND 9.11 adds two more stops on the knob

There will be an option to add these stops or, by default, bind-9.11 will care 
about this?

Thank you
Francesco


Da: bind-users [bind-users-boun...@lists.isc.org] per conto di Mark Andrews 
[ma...@isc.org]
Inviato: venerdì 23 settembre 2016 1.21
A: Reindl Harald
Cc: bind-us...@isc.org
Oggetto: Re: Minimal responses and speeding up queries

In message <218818d8-5ab8-40b0-fbc2-27c8966bb...@thelounge.net>, Reindl Harald
writes:
> Am 22.09.2016 um 22:41 schrieb Job:
> >>> If you want to avoid additional queries, turn minimal_responses off.
> >
> > I thought setting minimal_responses = yes should lower the number of querie
> s
> > Do you think it is the opposite?
>
> it's not about thinking - it's a fact
>
> just because without additional responses are part of the inital
> question and may save asking for that information - in case the
> additional info is not needed by the client it saves traffic
>
> just read what that option does and you know it

It's a response size vs number of queries trade off.   What is
"better" depends on how the clients process the answers returned,
the contents of the answers and what you want to achieve.  There
are lots of variables to this and they change over time.

In the end it is a knob.  BIND 9.11 adds two more stops on the knob.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/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: adding zone forwards without restart

[Matus UHLAR - fantomas]

Benny Pedersen  wrote:
> why does reload not flush ?



In article ,
Tony Finch  wrote:

Often you want to reload zone files without throwing away the cache.


On 22.09.16 11:39, Barry Margolin wrote:

It shouldn't flush the entire cache, but it would certainly make sense
to flush entries within a forwarding zone that's modified.


I don't see reason to implicitly flush entries just because existing domain
changed servers. Changing servers does not necessarily mean changing
content. 


there's "rndc flushtree" command since 9.9, that flushes domain and
subdomains when issued. You can use it if needed.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
How does cat play with mouse? cat /dev/mouse
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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