Re: adding zone forwards without restart
On 21.09.16 14:49, philippe.simo...@swisscom.com wrote: and after a forward add a rndc flush can help too .. not needed unless old forwarders provide invalid data. -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matus UHLAR - fantomas Sent: Wednesday, September 21, 2016 10:03 AM To: bind-users@lists.isc.org Subject: Re: adding zone forwards without restart On 2016-09-21 02:40, Frank Even wrote: Is there a way to add forwarders for specific zones without a restart? Everything I've read seems to indicate an "rndc reconfig" or an "rndc reload" should take care of this, but they do not. I add forwarders to "named.conf" and neither will load the new forwarded zone until I do a full daemon restart. On 20.09.16 19:44, Frank Even wrote: The basics are fine. BIND just doesn't load newly added forwarded zones, period. It also kind of lies in the output: the reconfig SHOULD cause bind reload the configuration. the reload SHOULD cause bind reload the zones. if it does not, it's probably a bug. for forwarding zones, reconfig should be enough. -- 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. Support bacteria - they're the only culture some people have. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Wildcard
Hi, Greetings. When we have "something.*." with cname record, if we query domain as "something.abc." , bind is not returning answer and if i query with same name "something.*.", getting answer in bind. When we have widlcard in middle labels, are we not treating as wildcard record? Kindly share info. Do we have any specific RFC for this. Thanks & Regards, Ramesh ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Wildcard
In message , rams writes: > > Hi, > Greetings. When we have "something.*." with cname record, if we > query domain as "something.abc." , bind is not returning answer and > if i query with same name "something.*.", getting answer in bind. > When we have widlcard in middle labels, are we not treating as wildcard > record? Kindly share info. > Do we have any specific RFC for this. > > Thanks & Regards, > Ramesh That isn't how wildcard records work. something.abc. matches *. See RFC 1034 Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Wildcard
Am 22.09.2016 um 14:37 schrieb rams: Greetings. When we have "something.*." with cname record, if we query domain as "something.abc." , bind is not returning answer and if i query with same name "something.*.", getting answer in bind. When we have widlcard in middle labels, are we not treating as wildcard record? Kindly share info. Do we have any specific RFC for this Google "dnf rfc wildcards" points to https://tools.ietf.org/html/rfc4592 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Wildcard
rams wrote: > When we have widlcard in middle labels, are we not treating as wildcard > record? In the DNS, a wildcard only occurs when the leftmost label is a *. > Do we have any specific RFC for this. https://tools.ietf.org/html/rfc4592#section-2.1 NOTE that wildcard rules can be confusingly different, in particular the rules for X.509 wildcards are incompatible with DNS wildcards except for the most simple uses. https://tools.ietf.org/html/rfc6125#section-6.4.3 Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Cromarty, Forth: Variable 3 or 4, becoming south or southwest 5 or 6. Slight or moderate. Showers. Moderate or good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Minimal responses and speeding up queries
Hello, in Bind 9.10 we tried minimal-responses = yes to limit "additional queries" when resolving. I notice that resolution is faster. Actually, dig @host some_url still shows an additional query, maybe not needed for a caching-only resolver: ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54581 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 Is there a way to improve limiting of "additional queries" after minimal-responses = yes? Thank you Francesco ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Minimal responses and speeding up queries
Job wrote: > > Actually, dig @host some_url still shows an additional query, maybe not > needed for a caching-only resolver: > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 That isn't an additional query, it's a record in the additional section of the response - specifically the OPT record which includes the EDNS buffer size, DNSSEC flag, and other extensions. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Malin, Hebrides: South or southwest 5 to 7, occasionally gale 8 later. Rough, occasionally very rough. Squally showers, rain later. Good becoming moderate or 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
Re: adding zone forwards without restart
In article , Tony Finch wrote: > Benny Pedersen wrote: > > > > why does reload not flush ? > > Often you want to reload zone files without throwing away the cache. It shouldn't flush the entire cache, but it would certainly make sense to flush entries within a forwarding zone that's modified. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Minimal responses and speeding up queries
On 22.09.16 16:41, Job wrote: in Bind 9.10 we tried minimal-responses = yes to limit "additional queries" when resolving. I notice that resolution is faster. Actually, dig @host some_url still shows an additional query, maybe not needed for a caching-only resolver: ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54581 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 Is there a way to improve limiting of "additional queries" after minimal-responses = yes? using minimal responses often results into additional queries needed, by definition. If you want to avoid additional queries, turn minimal_responses off. -- 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. "Two words: Windows survives." - Craig Mundie, Microsoft senior strategist "So does syphillis. Good thing we have penicillin." - Matthew Alton ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
adding second zone
Hi all I searching for about add a second zone to BIND but I didn't find how :-/ I've a standard zone: example1 IN SOA with record A 192.168.1.212 this zone works perfectly I'd like add a second zone to network 192.168.10.0/24, the problem is that my server has 1NIC and is connect to hardware firewall with some NICS, so: WAN<-->LAN1 - 192.168.1.0/24 <---> BIND+DHCP server (works) LAN2 - 192.168.10.0/24 <---> DHCP only LAN3 [...] LAN4 [...] routing and NAT works between LAN1 and LAN2 so, firewall will assign dhcp lease inside LAN2 with BIND on LAN1 any idea? thanks for help! 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: adding second zone
In article ,
Pol Hallen wrote:
> Hi all
> I searching for about add a second zone to BIND but I didn't find how :-/
Add
zone "secondzone.com" {
...
};
to your named.conf.
>
> I've a standard zone: example1 IN SOA with record A 192.168.1.212
>
> this zone works perfectly
>
> I'd like add a second zone to network 192.168.10.0/24, the problem is
> that my server has 1NIC and is connect to hardware firewall with some
> NICS, so:
>
> WAN<-->LAN1 - 192.168.1.0/24 <---> BIND+DHCP server (works)
> LAN2 - 192.168.10.0/24 <---> DHCP only
> LAN3 [...]
> LAN4 [...]
>
> routing and NAT works between LAN1 and LAN2
>
> so, firewall will assign dhcp lease inside LAN2 with BIND on LAN1
None of this has anything to do with BIND zones. You can serve multiple
zones on the same nameserver IP.
--
Barry Margolin
Arlington, MA
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Multiple $TTL values
Hello, We've recently noticed multiple $TTL values in transferred zonefiles which do not exist in the original zonefiles. They appear to be aggregates of TTLs set for individual records and I am definitely a fan of the organized look and feel. However, I am curious about how they should be interpreted where $ORIGIN is concerned. I just re-read rfc2308 and it states quite simply: " All resource records appearing after the directive, and which do not explicitly include a TTL value, have their TTL set to the TTL given in the $TTL directive. " My confusion is $ORIGIN basically defines the default origin while reading in the file and creates a mini-universe for interpreting records until redefined. Would a $TTL after a $ORIGIN be encapsulated by and restricted to records within that $ORIGIN block? My gut tells me no, and to follow the RFC literally (or loosely stated "from this point down") but looking at the file it seems as if the $TTL is intended to be for the records within the $ORIGIN only (i.e. it is not reset to global value at the end). I need to investigate this more on my own but I thought it might prove useful to ask the group as part of my research. Thanks in advance, John -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ Please visit https://lists.isc.org/mailman/listinfo/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 $TTL values
On Thu, Sep 22, 2016 at 3:36 PM, Woodworth, John R < john.woodwo...@centurylink.com> wrote: > Hello, > > > > We’ve recently noticed multiple $TTL values in transferred zonefiles which > do not exist in the original zonefiles. They appear to be aggregates of > TTLs set for individual records and I am definitely a fan of the organized > look and feel. > > > > However, I am curious about how they should be interpreted where $ORIGIN > is concerned. I just re-read rfc2308 and it states quite simply: > > “ All resource records appearing after the directive, and which do not > > explicitly include a TTL value, have their TTL set to the TTL given > > in the $TTL directive. “ > > > > My confusion is $ORIGIN basically defines the default origin while reading > in the file and creates a mini-universe for interpreting records until > redefined. Would a $TTL after a $ORIGIN be encapsulated by and restricted > to records within that $ORIGIN block? > > > > My gut tells me no, and to follow the RFC literally (or loosely stated > “from this point down”) but looking at the file it seems as if the $TTL is > intended to be for the records within the $ORIGIN only (i.e. it is not > reset to global value at the end). > > > > I need to investigate this more on my own but I thought it might prove > useful to ask the group as part of my research. > > > > > > Thanks in advance, > > John > > > This is a common point of confusion. DNS does not transfer zoneFILES. Zone files are read and converted into the in-memory tree structure. Zones are sent in wire format from the in-memory tree. The receiving end populates its in-memory tree. It can then convert the information to zone file format, and write it out, but do not expect it to look anything like the original zone file. It has no idea what the original file looked like, or what order the records were in. $ORIGIN and $TTL only apply to the zone they are in, so no need to reset them at the end of the file since they cease to exist at that point. They apply "from this line down until changed" and are merely a convenience to shorten the size of the file. -- Bob Harold ___ Please visit https://lists.isc.org/mailman/listinfo/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
Hi Matus, >>If you want to avoid additional queries, turn minimal_responses off. I thought setting minimal_responses = yes should lower the number of queries Do you think it is the opposite? Thank you again! Francesco Da: bind-users [bind-users-boun...@lists.isc.org] per conto di Matus UHLAR - fantomas [uh...@fantomas.sk] Inviato: giovedì 22 settembre 2016 17.07 A: bind-users@lists.isc.org Oggetto: Re: Minimal responses and speeding up queries On 22.09.16 16:41, Job wrote: >in Bind 9.10 we tried minimal-responses = yes to limit "additional queries" >when resolving. > >I notice that resolution is faster. >Actually, dig @host some_url still shows an additional query, maybe not needed >for a caching-only resolver: > >; (1 server found) >;; global options: +cmd >;; Got answer: >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54581 >;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > >Is there a way to improve limiting of "additional queries" after >minimal-responses = yes? using minimal responses often results into additional queries needed, by definition. If you want to avoid additional queries, turn minimal_responses off. -- 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. "Two words: Windows survives." - Craig Mundie, Microsoft senior strategist "So does syphillis. Good thing we have penicillin." - Matthew Alton ___ Please visit https://lists.isc.org/mailman/listinfo/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
Hi Tony, >>it's a record in the additional section of the response - specifically the OPT record which includes the EDNS buffer size, DNSSEC flag, and other extensions Is there an option to disable completely the OPT record information provided from Bind? Thank you! Francesco Da: Tony Finch [d...@dotat.at] Inviato: giovedì 22 settembre 2016 16.52 A: Job Cc: bind-users@lists.isc.org Oggetto: Re: Minimal responses and speeding up queries Job wrote: > > Actually, dig @host some_url still shows an additional query, maybe not > needed for a caching-only resolver: > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 That isn't an additional query, it's a record in the additional section of the response - specifically the OPT record which includes the EDNS buffer size, DNSSEC flag, and other extensions. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Malin, Hebrides: South or southwest 5 to 7, occasionally gale 8 later. Rough, occasionally very rough. Squally showers, rain later. Good becoming moderate or 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
RE: Multiple $TTL values
> This is a common point of confusion. DNS does not transfer > zoneFILES. Zone files are read and converted into the > in-memory tree structure. Zones are sent in wire format > from the in-memory tree. The receiving end populates its > in-memory tree. It can then convert the information to > zone file format, and write it out, but do not expect it > to look anything like the original zone file. It has no > idea what the original file looked like, or what order the > records were in. > > $ORIGIN and $TTL only apply to the zone they are in, so no > need to reset them at the end of the file since they cease > to exist at that point. They apply "from this line down > until changed" and are merely a convenience to shorten > the size of the file. > > -- > Bob Harold > > Bob, Thanks for your response. Although I was aware the zone data is transferred in wire-format between nameservers I was more concerned with the processing of the file when it is read (i.e. on startup, reconfig, etc.) We are "lucky" enough to be importing more zones into a DB backed provisioning system and as bind is getting more and more strict with each release regarding transfers we have scrapped our older scrubbing logic and started using bind to provide this service and couldn't be happier. Just wanted to confirm this $TTL logic was exactly as I suspected before requiring code changes (non-bind). Thanks again, John -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ Please visit https://lists.isc.org/mailman/listinfo/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
minimal-responses affects the size and not the number of responses. On Sep 22, 2016 23:44, "Job" wrote: > Hi Matus, > > >>If you want to avoid additional queries, turn minimal_responses off. > > I thought setting minimal_responses = yes should lower the number of > queries > Do you think it is the opposite? > > Thank you again! > Francesco > > > Da: bind-users [bind-users-boun...@lists.isc.org] per conto di Matus > UHLAR - fantomas [uh...@fantomas.sk] > Inviato: giovedì 22 settembre 2016 17.07 > A: bind-users@lists.isc.org > Oggetto: Re: Minimal responses and speeding up queries > > On 22.09.16 16:41, Job wrote: > >in Bind 9.10 we tried minimal-responses = yes to limit "additional > queries" when resolving. > > > >I notice that resolution is faster. > >Actually, dig @host some_url still shows an additional query, maybe not > needed for a caching-only resolver: > > > >; (1 server found) > >;; global options: +cmd > >;; Got answer: > >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54581 > >;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > > >Is there a way to improve limiting of "additional queries" after > minimal-responses = yes? > > using minimal responses often results into additional queries needed, by > definition. If you want to avoid additional queries, turn > minimal_responses > off. > > -- > 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. > "Two words: Windows survives." - Craig Mundie, Microsoft senior strategist > "So does syphillis. Good thing we have penicillin." - Matthew Alton > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Minimal responses and speeding up queries
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 queries 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 ___ Please visit https://lists.isc.org/mailman/listinfo/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
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
Re: R: Minimal responses and speeding up queries
In article , Job wrote: > I thought setting minimal_responses = yes should lower the number of queries > Do you think it is the opposite? Yes. With minimal_response = no, it doesn't fill in the Additional section with records related to the ones in the Answer section. If the client doesn't already have those records cached, it will need to make an additional query to get them. So instead of one query that returns everything the client needs, it needs to make two queries. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
