Re: Stopping ddos

[KEVIN DARCY via bind-users]

I've never actually used RRL, but from the manual, it appears to default to a 
/24 prefix length to determine whether IPv4 clients are "similar" enough to be 
lumped in the same bucket, for RRL purposes. That might need to be tweaked, 
depending on the profile of whoever is attacking/abusing you. The option is 
ipv4-prefix-length. IPv6 has a similar option, defaulting to /56.

From your partial log extract, it looks like you're getting hit from different 
parts of the 114.29.192.0/19 netblock (which, according to APNIC, appears to 
belong to WebEx/Cisco). That's why I suggested you might want to tweak those 
settings.

From the ARM, it looks like there are other configuration parameters too -- 
responses-per-second, nodata-per-second, nxdomains-per-second, 
referrals-per-second -- presumably all intended to provide fine-grained 
protection with minimal false positives.

I would recommend a thorough reading of the ARM, and perhaps consultation with 
DNS admins who have practical experience with RRL. Hopefully there are some on 
this list.

If you have a robust IPS in place, it should be possible, with the appropriate 
signature/rule, to drop all​ incoming root-domain queries. That's a pretty 
drastic solution, though, and there could be fallout.

- Kevin

From: bind-users  on behalf of Richard T.A. 
Neal 
Sent: Tuesday, August 2, 2022 5:20 PM
To: r...@htt-consult.com ; bind-users@lists.isc.org 

Subject: RE: Stopping ddos

>> Any best practices on this?
>>
>> I am running bind 9.11.4
>>
>> thanks

> You could think about adding fail2ban to your server with some custom rules.
> Helped us in a similar situation.

You could also take advantage of BIND's built-in Response Rate Limiting which 
is explained here:
https://downloads.isc.org/isc/bind9/9.16.31/doc/arm/html/reference.html#response-rate-limiting

I  don't recall if BIND 9.11 supports that feature, but even if it does you 
should really be upgrading to 9.16.31 anyway (the latest Current-Stable, ESV).

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

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


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

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


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

Re: Resolve any query to same IP address

[Kevin Darcy via bind-users]

[ Classification Level: GENERAL BUSINESS ]

Dot "." instead of asterisk "*" as the zone name. Remove the "hint" zone,
since that doesn't apply when you host your own root zone.

You need a proper MNAME for the SOA RR too.

- Kevin

On Wed, Jul 21, 2021 at 11:18 AM Jeronimo  wrote:

> Hi,
>
> how can I get the same IPv6 address as the answer to any query to my Bind9?
>
> I am using Ubuntu 20 and Bind 9.11 whit configuration as bellow:
>
> --
> $ cat /etc/bind/named.conf
> include "/etc/bind/named.conf.options";
> include "/etc/bind/named.conf.local";
> include "/etc/bind/named.conf.default-zones";
> --
> $ cat /etc/bind/named.conf.options
> options {
> directory "/var/cache/bind";
> recursion no;
> querylog yes;
> listen-on-v6 { any; };
> dnssec-validation auto;
> auth-nxdomain no;# conform to RFC1035
> };
> 
> $ cat /etc/bind/named.conf.default-zones
> zone "." {
>  type hint;
>  file "/etc/bind/db.root";
> };
>
> zone "localhost" {
>  type master;
>  file "/etc/bind/db.local";
> };
>
> zone "127.in-addr.arpa" {
>  type master;
>  file "/etc/bind/db.127";
> };
>
> zone "0.in-addr.arpa" {
>  type master;
>  file "/etc/bind/db.0";
> };
>
> zone "255.in-addr.arpa" {
> type master;
>  file "/etc/bind/db.255";
> };
>
> zone "*" {
>  type master;
>  file "/etc/bind/db.fakeroot";
> };
> --
> $ cat db.fakeroot
> $TTL 30
> @ IN SOA * hostmaster.mydomain.com. (
> 1 ; Serial
> 240 ; Refresh
> 120 ; Retry
> 900 ; Expire
> 300 ; Negative Cache TTL
> )
> ;
>   IN NS 
> * IN  
>
> Any help is welcome.
>
> Regards,
>
> Jeronimo
>
> ___
> 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

Re: query-source and listened interfaces

[Kevin Darcy via bind-users]

[ Classification Level: GENERAL BUSINESS ]


I've done the match-destinations/query-source thing before, but in addition
to that, it should theoretically be possible to also use a shared cache
between the views, via attach-cache. I've never played with that directive
myself, however.


  - Kevin

On Mon, Jul 12, 2021 at 5:32 AM Petr Menšík  wrote:

> Hi Xinyu.
>
> Why would you need client-facing IP address to appear on authoritative
> servers? It should be more or less independent.
>
> I think it might be possible to use views and match-destination combined
> with query-source for each view. But it seems similar to running separate
> bind instances. I think it would have different cache anyway.
>
> Can you share why source addresses are important?
>
> Cheers,
>
> Petr
> On 7/8/21 9:08 AM, Xinyu Wang wrote:
>
> Hi guys,
>
> Is it possible to make a recursive BIND send queries to authorities from
> the interface which the original query was sent to.
>
> For instance,
> the recursive BIND is listening 3 interfaces, they are 1.1.1.1, 1.1.1.2,
> and 1.1.1.3
>
> when a  recusive query arrived at 1.1.1.1, then BIND use 1.1.1.1 to
> complete the recursion process.
>
> when a  recusive query arrived at 1.1.1.2, then BIND use 1.1.1.2 to
> complete the recursion process.
>
> when a  recusive query arrived at 1.1.1.3, then BIND use 1.1.1.3 to
> complete the recursion process.
>
> Hopefully I made myself clear, and looking  forward to some help.
> Thanks
>
>
>
> --
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemen...@redhat.com
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>
> ___
> 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

Re: Managing localhost

[Kevin Darcy via bind-users]

[ Classification Level: GENERAL BUSINESS ]


That chapter doesn't show any PTR records, for the reverse zones of any
*public* address range, pointing back to a "localhost" name. It only shows
a PTR record in the reverse zone for the 127.0.0/24 private range, which is
what enables a reverse lookup for 127.0.0.1. Your ISP isn't (or shouldn't
be) hosting reverse zones for any range under the 127/8 private block, on
your behalf. That's your responsibility; hence the term "private".

And, as Tony mentioned, these days it's highly questionable whether
"localhost" entries in *any* zone, forward or reverse, serve any useful
purpose, and may actually cause harm.


- Kevin

On Mon, Jun 21, 2021 at 12:48 PM  wrote:

> Hi,
>
> This book  :
> https://www.oreilly.com/library/view/dns-and-bind/0596100574/ch04.html
> says I should manage the localhost within my zone (SOA) and reverse
> lookup / PTR.
>
> I do not manage my revers lookup / PTR the IP owner does that.
>
> Any thoughts on managing the localhost within the zone file and PTR?
>
> Thanks!!
> ___
> 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

Re: How to return REFUSED

[Kevin Darcy via bind-users]

[ Classification Level: GENERAL BUSINESS ]

I just checked the ARM, and it denotes that "match-recursive-only"
(boolean) still exists for views. So, you might be able to set up a special
view with that, as well as a negated match-clients, specifying allow-query
{ none; }. Put it as the first view, and both non-recursive queries, and
queries from your "recursive-users" ACL, will fall through to subsequent
views.


- Kevin

P.S. ISC's "understanding views" knowledgebase article doesn't mention
match-recursive-only, so there is a discrepancy there. Either the feature
has been removed, and the ARM documentation hasn't been updated to reflect
it, or the knowledgebase article only focuses on the most common
view-matching criteria, omitting match-recursive-only, since the use cases
for that are very rare.


On Wed, May 5, 2021 at 3:10 PM Axel Rau  wrote:

> I have,
>
> allow-query { any; };
> allow-query-cache { recursive-users; };
> allow-recursion { recursive-users; };
>
> How can I make sure that none recursive-users get a REFUSED if query is
> recursive?
>
> Axel
>
> PS: I want to minimize the responses to this amplification attack:
> - - -
> 19:05:18.703238 185.230.55.130.30120 > 91.216.35.71.53: [no udp cksum] 1+
> RRSIG? pizzaseo.com.(30) (ttl 249, id 33043, len 58)
> 19:05:18.703568 91.216.35.71.53 > 185.230.55.130.30120: [udp sum ok] 1- q:
> RRSIG? pizzaseo.com. 0/13/14 ns: com. NS j.gtld-servers.net., com. NS
> m.gtld-servers.net., com. NS c.gtld-servers.net., com. NS
> b.gtld-servers.net., com. NS d.gtld-servers.net., com. NS
> e.gtld-servers.net., com. NS l.gtld-servers.net., com. NS
> f.gtld-servers.net., com. NS h.gtld-servers.net., com. NS
> i.gtld-servers.net., com. NS a.gtld-servers.net., com. NS
> k.gtld-servers.net., com. NS g.gtld-servers.net. ar: m.gtld-servers.net.
> A 192.55.83.30, l.gtld-servers.net. A 192.41.162.30, k.gtld-servers.net.
> A 192.52.178.30, j.gtld-servers.net. A 192.48.79.30, i.gtld-servers.net.
> A 192.43.172.30, h.gtld-servers.net. A 192.54.112.30, g.gtld-servers.net.
> A 192.42.93.30, f.gtld-servers.net. A 192.35.51.30, e.gtld-servers.net. A
> 192.12.94.30, d.gtld-servers.net. A 192.31.80.30, c.gtld-servers.net. A
> 192.26.92.30, b.gtld-servers.net. A 192.33.14.30, a.gtld-servers.net. A
> 192.5.6.30, m.gtld-servers.net.  2001:501:b1f9::30(490) (ttl 63, id
> 11754, len 518)
> - - -
> ---
> PGP-Key: CDE74120  ☀  computing @ chaos claudius
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
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: Bind9 weighted load balancing

[Kevin Darcy via bind-users]

[ Classification Level: GENERAL BUSINESS ]

Duplicate RRs are suppressed, as per the standards.

RFC 2181, Section 5:

Each DNS Resource Record (RR) has a label, class, type, and data.  It
   is meaningless for two records to ever have label, class, type and
   data all equal - servers should suppress such duplicates if
   encountered


That being said, a DNS-based load-balancer can probably do what you're
looking for.

- Kevin

On Fri, Apr 30, 2021 at 3:44 PM Alperen Yılmaz 
wrote:

> Hello everyone,
>
> There is a round robin resolving mechanism in bind9 where the server
> chooses different records to resolve for each request, but is there a way
> to assign weights so that the server resolves with different probabilities?
>
> All I could find about the topic was this old mail from the archive:
> https://lists.isc.org/pipermail/bind-users/2007-April/066194.html
> It says you can put duplicate records for increasing the weight, however
> it also says that bind9 does not seem to support this.
>
> hostIN A 1.2.3.4
> IN A 1.2.3.4
> IN A 1.2.3.4
> IN A 1.2.3.5
>
>
> Thank you,
> Alperen Yılmaz
> ___
> 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

Re: Configuring the location of named .jnl files

[Kevin Darcy via bind-users]

[ Classification Level: GENERAL BUSINESS ]

Ivan,
   I've never done the Let's Encrypt thing myself, but from my skim
of the documentation, it appears they want you to place a TXT record in a
specific part of your domain's namespace hierarchy.

I sincerely hope you're not trying to write the TXT record directly to the
journal file. That could lead to corruption, or, at the very least, your
changes could be overwritten, since journal files are written dynamically.

The safe way to update DNS programmatically is through the Dynamic Update
extension to DNS, typically via the "nsupdate" command-line utility, or via
various libraries/modules of scripting languages like Perl or Python.

One of the bash-based ACME client implementations linked from Let's
Encrypt's webpage, for instance, is github.com/bruncsak/ght-acme.sh, and
for the DNS-01 challenge method, it feeds some commands to nsupdate. The
code is rather crude, assuming no crypto-based authentication on the server
side, among other things, but it's at least a start on a recommended way to
update DNS data. Better than mucking around with journal files.

There is a learning curve associated with Dynamic Update. On the server
side, for instance, you'll need to establish permissions via allow-update.
Limiting updates to localhost at least would protect your DNS data from
unauthorized changes from remote hosts, but ideally, you'd generate a key
and use that.


 - Kevin

On Sun, Apr 25, 2021 at 7:39 PM Ivan Avery Frey 
wrote:

> I'm trying to obtain certificates from Let's Encrypt using the DNS-01
> challenge method.
>
> I just want to confirm that there is no option to configure the
> directory for the .jnl files independently of the zone files.
> ___
> 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

Re: Preventing a particular type of nameserver abuse

[Kevin Darcy via bind-users]

[ Classification Level: GENERAL BUSINESS ]


It's not a "BIND" solution, per se, but if you have a
sufficiently-sophisticated IPS (Intrusion Prevention System) you could have
it simply drop all queries of a particular QNAME, or any particular
combination of QNAME, QTYPE, QCLASS, before those packets even get to
named. I know SNORT-based IPSes can do this, not so sure about other IPSes,
but most of them have a custom rule/signature capability. As Grant pointed
out, it wouldn't even need to be a dedicated IPS -- one could potentially
leverage that IPS capabilities of a firewall.


  - kevin

On Mon, Apr 12, 2021 at 4:10 PM Peter Coghlan  wrote:

> Hello,
>
> I have a nameserver which is authoritative for three or four domain names.
> It receives around 1000 queries per day that could be regarded as plausably
> legitimate.  It receives around ten times that number of absive queries per
> day from presumably spoofed ip addresses, the vast majority of them IN ANY
> queries for the "sl" domain or for the root nameservers all of which my
> nameserver responds to with return code 5 ie refused.
>
> In many cases, the source port is a low number such as 53, 80, 96 or 443
> for example which might make some sense if these were TCP queries but they
> are all UDP queries and apart from attempting to target port 53, attempting
> to target the other low UDP port numbers make no sense to me.
>
> I have searched high up and low down for any discussion about this kind
> of abuse and found very little regarding abusive queries for the root
> nameservers, none at all regarding the sl domain (although it is a
> difficult
> term to search for) and nothing at all regarding the oddball source ports
> either.
>
> Even though the "refused" responses from my nameserver are "small", the
> general persistence of the abusers over a long period of time suggests to
> me that they are finding these queries effective for some kind of abuse,
> perhaps by way of having a very large number of nameservers return them
> (unless they are too stupid to care whether the queries are answered or
> refused which I suppose is also possible).
>
> As far as I can see providing no response at all in any instance when a
> code 5 refused response would normally be returned would be the appropriate
> thing for my nameserver to do here and doing this would cause no
> difficulties
> at all with any legitimate queries or anyone who is not an abuser.  Am I
> correct here?
>
> I have searched for a way to prevent my nameserver from responding
> to these queries at all in order to reduce the impact on the targets
> of this abuse.  All results of my research point to the use of
> rate limiting as the only approach available for dealing with this
> sort of issue.
>
> The abusive queries are clearly designed to circumvent the widely
> suggested "errors-per-second 5" as they arrive in groups of five
> per second and applying this limitation has little or no effect
> on them.
>
> I have tried "errors-per-second 1" and this seems to reduce the abuse
> by about four fifths but one fifth of it still manages to get through
> and I don't find this acceptable.
>
> Instead, when I notice particularly heavy abuse of my nameserver,
> I apply packet filtering to prevent the abusive queries from reaching
> my nameserver and therefore to prevent it responding to them.  I
> also routinely packet filter all UDP dns queries with source port
> numbers less than 1024 which I hope is the appropriate cutoff point.
>
> Is there anything else I can do to reduce the impact of this abuse
> of my nameserver on others?
>
> My feeling is that mine can't be the only nameserver experiencing this
> kind of abuse and that many nameserver admins probably would not even
> notice it unless they had query logging or query-error logging turned
> on and checked the logs.
>
> Regards,
> Peter Coghlan.
>
> --Boundary_(ID_/cANmbMgveXk/KlZF+xdIQ)--
> ___
> 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

Re: Logging on a Bind server

[Kevin Darcy]

[ Classification Level: GENERAL BUSINESS ]

Sorry to follow up on my own post, but I feel I should add a caveat about
blocking IPs -- the resolution of ns2.honeypot.us could *change* over time,
so an IP-based block might not be effective in the long term, and in fact
might cause more harm than good.

If you truly want to block any communication with ns2.honeypot.us by
*name*, permanently, you'd probably have to go to the extreme of creating a
zone for just that particular name, resolve it to 0.0.0.0, something of
that nature.

In the larger picture, you might want to consider, instead, a dynamic,
reputation-based RPZ feed. See https://dnsrpz.info/ for more.

- Kevin

On Tue, Oct 20, 2020 at 10:45 AM Kevin Darcy 
wrote:

> [ Classification Level: GENERAL BUSINESS ]
>
> According to securitytrails.com (for instance), there are over 3,000
> domains hosted on ns2.honeybot.us (securitytrails only shows the first
> few domains hosted -- to see more, one presumably needs a subscription to
> their service).
>
> If one of your clients looked up a name in one of those 3,000+ domains,
> your BIND instance will potentially reach out to that nameserver to resolve
> the name.
>
> As far as BIND logging, I don't know the best way to track this, offhand,
> short of cranking up debug to ridiculous levels, and wading through the
> verbose output. This might take significant resources (storage, CPU, etc.)
>
> It might be easier to run a packet capture, looking for something sent to
> the specific IP associated with ns2.honeybot.us. Or, if you have a robust
> Intrusion Prevention/Detection System (IPS or IDS), maybe configure an
> "alert" rule for that destination IP. For either option, it might also be
> interesting to see the response from ns2.honeybot.us, to check for
> shenanigans.
>
> If you just want to mitigate any danger, and are willing to deal with any
> fallout, you could just block the IP, on your firewall or IPS or with
> BIND's "blackhole" feature.
>
>   - Kevin
>
> On Tue, Oct 20, 2020 at 10:17 AM  wrote:
>
>> Dear BIND-Users,
>>
>> We use in our environment a BIND Server. It works properly.
>> One Day it came an alert from Cybereason (Antivirus-Software), that our
>> Bind server tried to Connect to a suspicious domain "ns2.honeybot.us".
>> But I couldn’t find the log,  which domain the BIND server was searching
>> for, so that the BIND server has to connect to "ns2.honeybot.us". I can
>> see the Queries log, which domain the Clients were querying but I couldn’t
>> find out why our Bind Server tried to connect the name server "
>> ns2.honeybot.us".
>>
>> Does someone has an idea, which log I have to activate.
>>
>> Thank you for your help in advance.
>>
>> Best Regards
>> Senthan
>>
>> --
>>
>> Schwyzer Kantonalbank
>>
>> Senthan Sivasundaram
>>
>> IT Systems
>>
>> Postfach 263
>>
>> 6431 Schwyz
>>
>>
>>
>> Tel. +41 (0)58 800 29 88
>>
>> Fax +41 (0)58 800 20 21
>>
>> senthan.sivasunda...@szkb.ch
>>
>> www.szkb.ch
>>
>>
>>
>> [image: http://www.szkb.ch/files/png1/facebook.png]
>> <https://www.facebook.com/szkb.ch>  [image:
>> http://www.szkb.ch/files/png1/xing.png]
>> <https://www.xing.com/companies/schwyzerkantonalbank>  [image:
>> http://www.szkb.ch/files/png1/youtube.png]
>> <https://www.youtube.com/schwyzerkantonalbank>
>>
>>
>>
>>
>> Gut beraten, Schwyzer Art. - SZKB-Newsletter abonnieren
>> <https://www.szkb.ch/pub/ueber-die-szkb/servicezentrum/bestellen/newsletter-abonnieren>
>>
>>
>> Aufgrund der bisherigen E-Mail-Korrespondenz bzw. getroffener Absprachen,
>> erachtet sich die SZKB als berechtigt, mit Ihnen per E-Mail zu
>> kommunizieren. Die SZKB geht davon aus, dass Sie die Risiken von E-Mails
>> kennen und in Kauf nehmen. So sind namentlich gewöhnliche,
>> unverschlüsselte, E-Mails, die über das Internet gesendet werden, weder
>> vertraulich noch sicher. Es besteht die Gefahr von Manipulation oder
>> Missbrauch durch Dritte, Fehlleitung, verzögerte Übermittlung oder
>> Bearbeitung, Anhang von Viren, Malware usw. Die SZKB lehnt jede Haftung für
>> Schäden im Zusammenhang mit der Verwendung von E-Mails ab, sofern sie die
>> geschäftsübliche Sorgfalt nicht verletzt hat.
>>
>> E-Mails werden nur während den üblichen Geschäftszeiten der SZKB
>> bearbeitet. Sie können nicht von der sofortigen Kenntnisnahme Ihrer E-Mai

Re: Logging on a Bind server

[Kevin Darcy]

[ Classification Level: GENERAL BUSINESS ]

According to securitytrails.com (for instance), there are over 3,000
domains hosted on ns2.honeybot.us (securitytrails only shows the first few
domains hosted -- to see more, one presumably needs a subscription to their
service).

If one of your clients looked up a name in one of those 3,000+ domains,
your BIND instance will potentially reach out to that nameserver to resolve
the name.

As far as BIND logging, I don't know the best way to track this, offhand,
short of cranking up debug to ridiculous levels, and wading through the
verbose output. This might take significant resources (storage, CPU, etc.)

It might be easier to run a packet capture, looking for something sent to
the specific IP associated with ns2.honeybot.us. Or, if you have a robust
Intrusion Prevention/Detection System (IPS or IDS), maybe configure an
"alert" rule for that destination IP. For either option, it might also be
interesting to see the response from ns2.honeybot.us, to check for
shenanigans.

If you just want to mitigate any danger, and are willing to deal with any
fallout, you could just block the IP, on your firewall or IPS or with
BIND's "blackhole" feature.

  - Kevin

On Tue, Oct 20, 2020 at 10:17 AM  wrote:

> Dear BIND-Users,
>
> We use in our environment a BIND Server. It works properly.
> One Day it came an alert from Cybereason (Antivirus-Software), that our
> Bind server tried to Connect to a suspicious domain "ns2.honeybot.us".
> But I couldn’t find the log,  which domain the BIND server was searching
> for, so that the BIND server has to connect to "ns2.honeybot.us". I can
> see the Queries log, which domain the Clients were querying but I couldn’t
> find out why our Bind Server tried to connect the name server "
> ns2.honeybot.us".
>
> Does someone has an idea, which log I have to activate.
>
> Thank you for your help in advance.
>
> Best Regards
> Senthan
>
> --
>
> Schwyzer Kantonalbank
>
> Senthan Sivasundaram
>
> IT Systems
>
> Postfach 263
>
> 6431 Schwyz
>
>
>
> Tel. +41 (0)58 800 29 88
>
> Fax +41 (0)58 800 20 21
>
> senthan.sivasunda...@szkb.ch
>
> www.szkb.ch
>
>
>
> [image: http://www.szkb.ch/files/png1/facebook.png]
>   [image:
> http://www.szkb.ch/files/png1/xing.png]
>   [image:
> http://www.szkb.ch/files/png1/youtube.png]
> 
>
>
>
>
> Gut beraten, Schwyzer Art. - SZKB-Newsletter abonnieren
> 
>
>
> Aufgrund der bisherigen E-Mail-Korrespondenz bzw. getroffener Absprachen,
> erachtet sich die SZKB als berechtigt, mit Ihnen per E-Mail zu
> kommunizieren. Die SZKB geht davon aus, dass Sie die Risiken von E-Mails
> kennen und in Kauf nehmen. So sind namentlich gewöhnliche,
> unverschlüsselte, E-Mails, die über das Internet gesendet werden, weder
> vertraulich noch sicher. Es besteht die Gefahr von Manipulation oder
> Missbrauch durch Dritte, Fehlleitung, verzögerte Übermittlung oder
> Bearbeitung, Anhang von Viren, Malware usw. Die SZKB lehnt jede Haftung für
> Schäden im Zusammenhang mit der Verwendung von E-Mails ab, sofern sie die
> geschäftsübliche Sorgfalt nicht verletzt hat.
>
> E-Mails werden nur während den üblichen Geschäftszeiten der SZKB
> bearbeitet. Sie können nicht von der sofortigen Kenntnisnahme Ihrer E-Mail
> ausgehen. Die SZKB ist grundsätzlich nicht verpflichtet, Aufträge oder
> Anweisungen, die per E-Mail erteilt werden, auszuführen, ausser dies wurde
> ausdrücklich vereinbart. Falls Sie diese E-Mail irrtümlich erhalten haben,
> ersuchen wir Sie, die E-Mail an den Absender zurückzusenden und die
> Nachricht mit allen Anhängen von ihrem System zu löschen.
>
>
>   Bitte denken Sie an die Umwelt - drucken Sie diese E-Mail nicht aus und
> sparen Sie pro Seite 100 ml Wasser, 7 g CO2 und 11 g Holz.
>
> Gut beraten, Schwyzer Art. - SZKB-Newsletter abonnieren
> 
>
>
> Aufgrund der bisherigen E-Mail-Korrespondenz bzw. getroffener Absprachen,
> erachtet sich die SZKB als berechtigt, mit Ihnen per E-Mail zu
> kommunizieren. Die SZKB geht davon aus, dass Sie die Risiken von E-Mails
> kennen und in Kauf nehmen. So sind namentlich gewöhnliche,
> unverschlüsselte, E-Mails, die über das Internet gesendet werden, weder
> vertraulich noch sicher. Es besteht die Gefahr von Manipulation oder
> Missbrauch durch Dritte, Fehlleitung, verzögerte Übermittlung oder
> Bearbeitung, Anhang von Viren, Malware usw. Die SZKB lehnt jede Haftung für
> Schäden im Zusammenhang mit der Verwendung von E-Mails ab, sofern sie die
> geschäftsübliche Sorgfalt nicht verletzt hat.
>
> E-Mails werden nur während den üblichen Geschäftszeiten der SZKB
> bearbeitet. Sie können nicht von der sofortigen Kenntnisnahme Ihrer 

Re: "forward first" set on a master zone not working as expected

[Kevin Darcy]

[ Classification Level: GENERAL BUSINESS ]

Or, if you absolutely *must* use the same namespace internally and
externally (oftentimes you can't talk the business out of that), your
internal version should be a more-or-less a superset of your external
version.

How you keep those in sync is up to you. For us, we have a centralized
management system that makes the relevant updates in parallel. The big
caveat with that is, those few situations where the DNS needs to be
"schizophrenic", i.e. resolve differently in the internal versus external
versions of the zones. We try to keep that nonsense to a minimum, but when
we can't talk people out of it, we handle it on an exception basis.

I suppose another approach is to have a backend database which tags each
record as being "internal", "external" or "both", and then the respective
versions of the zones get generated accordingly. You'd need something to
ensure referential integrity, though, otherwise you might end up with
dangling references (e.g. CNAME/MX/SRV targets), bad delegations, etc.


- Kevin

P.S. No offense to schizophrenics. I guess a more accurate term would be
"multiple personality".


On Thu, Sep 3, 2020 at 3:52 AM Matus UHLAR - fantomas 
wrote:

> On 02.09.20 15:00, Taylor Vierrether via bind-users wrote:
> > I am attempting to set up an internal DNS server that is authoritative
> for
> > internal resources, but also will respond for external resources on the
> > same domain that it does not have records for.
> >
> > For example, I have a domain sub.example.com , and I want to have
> internal
> > entries in the BIND zone file for host1.sub.example.com and
> > host2.sub.example.com.  That part is working fine.  However, there is a
> > publicly available DNS entry for sub.example.com that I want my internal
> > clients to be able to resolve, but I don’t want to have the IP in the
> BIND
> > zone file, because the IP is dynamic.
>
> you can delegate that entry elsewhere.
>
> >  There are also some hosts (host3.sub.example.com ) and
> > (host4.sub.example.com) that are externally resolvable that I don’t want
> > to put in my internal BIND file because they are not controlled by me.
> > (Think CNAME to a SaaS application)
>
> you can delegate those records somewhere.
>
> >I’ve attempted to do this as follows, and it seems to make sense that it
> > would work, but it does not.
> >
> >
> >named.conf:
> >
> >zone “sub.example.com" IN {
> >type master;
> >file "/etc/bind/sub.example.com.zone";
> >forward first;
> >forwarders { 1.1.1.1; 1.0.0.1; };
> >};
>
> forwarding is not used for zone other than "type forward".
>
> >What actually happens, is if I query for sub.example.com I get the
> following from nslookup:
> >*** Can't find sub.example.com: No answer
>
> if you search for "sub.example.com" record, you can not delegate that one,
> of course.
>
> you apparently should use redesign your DNS. Easiest way would be using
> different domain internally.
>
> >And if I query for host3.example.com , I get the following from nslookup:
> >** server can't find host3.sub.example.com: NXDOMAIN
>
> note that nslookup is very bad program for tracking DNS errors.
> use "host" or "dig" for that case.
>
>
> --
> 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.
> I just got lost in thought. It was unfamiliar territory.
> ___
> 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

Re: CNAME restrictions

[Kevin Darcy]

[ Classification Level: GENERAL BUSINESS ]

Offhand, it looks like the server side is configured to only allow
authenticated updates, but you're sending an unauthenticated one.

A more nuanced issue might be if the ID you're running the nsupdate as,
can't read the key files, so even though you may have intended the update
to be signed, it actually wasn't.

Did you try adding a -d to the nsupdate command? If so, does the debug
output give any clues?

 -
Kevin

On Tue, Aug 4, 2020 at 1:30 PM Leroy Tennison 
wrote:

> I have a situation where, due to the system's location (IP subnet), its
> DNS name is ..datavoiceint.com.  We have a
> certificate for *.datavoiceint.com which we prefer to use instead of
> having to acquire a certificate for .datavoiceint.com
> since this is a one-off internal-only web server.  Our (ISC) DNS servers
> (version 9.10.3-P4-Ubuntu that comes with Ubuntu 16.04) serve both
> domains.  I thought a solution would be to use a CNAME but, when I attempt
> this (via nsupdate with the update key which works for A and PTR adds and
> deletes) I get (on "send"):
>
>  TSIG error with server: expected a TSIG or SIG(0)
> update failed: NOTIMP
>
> What I tried (on both .datavoiceint.com. and
> datavoiceint.com.) was:
>
> update add .datavoiceint.com. 86400 IN CNAME . subdomain>.datavoiceint.com.
>
> Apparently I'm mis-understanding CNAME usage, if I actually can use a
> CNAME record what should the format be (or do I need to configure bind
> differently to use it since part of the reply is NOTIMP)?  If that's not
> possible due to CNAME restrictions are there any alternatives?
>
> Thanks for your help.
>
> Harriscomputer
>
>
> *Leroy Tennison*Network Information/Cyber Security Specialist
> E: le...@datavoiceint.com
> P:
>
>
> 2220 Bush Dr
> McKinney, Texas
> 75070
> www.datavoiceint.com 
>
> This message has been sent on behalf of a company that is part of the
> Harris Operating Group of Constellation Software Inc.
>
> If you prefer not to be contacted by Harris Operating Group please notify
> us .
>
>
>
> This message is intended exclusively for the individual or entity to which
> it is addressed. This communication may contain information that is
> proprietary, privileged or confidential or otherwise legally exempt from
> disclosure. If you are not the named addressee, you are not authorized to
> read, print, retain, copy or disseminate this message or any part of it. If
> you have received this message in error, please notify the sender
> immediately by e-mail and delete all copies of the message.
>
>
> ___
> 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

Re: Fun with nsudpate and ac1.nstld.com

[Kevin Darcy]

[ Classification Level: GENERAL BUSINESS ]


You didn't dot-terminate covisp.net in the "zone" statement, so it may be
appending who-knows-what to one of its queries, and going awry.

nsupdate -d (or -D) shows all :-)

 - Kevin

On Mon, Jul 6, 2020 at 6:32 PM @lbutlr  wrote:

> Trying to verify that I can make changes with nsupdatem and running into
> something I don’t understand.
>
>  mail # nsupdate -k admin.key
> > zone name covisp.net
> > update delete ns1.covisp.net. INA   65.121.55.42
> > update add ns1.covisp.net. 3601 INA   65.121.55.42
> > send
> ; Communication with 192.42.173.30#53 failed: timed out
>
> Uh… what? Why is it trying to update 192.42.173.30 (ac1.nstld.com)?
>
> That IP does not appear in any file in /usr/local/etc/ nor in /etc/ on my
> system.
>
> What am I missing here?
>
> In fact, the only file on the entire /usr/ that has this IP address in it
> is the draft copy of this email.
>
>
> ___
> 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

Re: How to get random subset of large rrset (30+ IPs for round robin)?

[Kevin Darcy]

[ Classification Level: GENERAL BUSINESS ]

Only thing that comes to mind is a constantly-running dynamic update script
that adds/deletes records to/from the RRset at random.

A more sophisticated version of the script would look at what answers that
have been given out in the recent past, and if some addresses were given
out more than others (because of the randomness), "tilt" the answer set
back more towards equal representation.


- Kevin

On Fri, Mar 20, 2020 at 3:15 AM David Klatt  wrote:

> Hi,
>
> I can't find a way to do the following although I invested plenty of time
> in research - maybe you guys have an idea:
>
> With bind, I'd need to serve a single A record with  30+  IP addresses  and
> these addresses have to be returned in random order round robin,
> which is done with:
>
> rrset-order {  order random;  };
>
> and records like:
>
> foo  IN A  10.0.0.1
> foo  IN A  10.0.0.2
> foo  IN A  10...N
>
> Now I'd like bind to just return a  random subset  of e.g. 5 IP addresses
> if someone requests this A record.
>
> Reason for this are in my case some (thousands) older clients (that I
> can't control)
> that seem not being able to handle that many IPs - the OS resolver just
> returns an error.
>
> For my use case I absolutely need to make sure that each IP of that large
> A record set is given out equally (statistically) and that at any time when
> bind answers that one A record it only returns a random subset of all
> these IPs.
>
> Has someone an idea on how to achieve the latter?
>
> Thanks a lot in advance!
>
> David
> Geschäftsführer: Christoph Ostermann (CEO), Oliver Koch, Steffen
> Schneider, Hermann Schweizer, Tim Ulbricht.
> Amtsgericht Kempten/Allgäu, Registernummer: 10655, Steuernummer
> 127/137/50792, USt.-IdNr. DE272208908
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Using TSIG Keys Between Linux OS and Windows OS

[Kevin Darcy]

[ Classification Level: PUBLIC ]

To clarify, the OP didn't specify what DNS software they were using, only
the OS (Windows 2016).

If using Microsoft DNS, then as Mark pointed out, Microsoft has not
implemented regular shared-key TSIG. They have, however, implemented
GSS-TSIG, which, I believe, can be configured on the BIND side (although
I've never personally done that).

If using BIND on Windows, then, as Chuck pointed out, configuration is no
different than any other BIND-to-BIND TSIG setup.

-
Kevin

On Mon, Nov 25, 2019 at 11:27 AM Chuck Aurora  wrote:

> On 2019-11-25 02:36, Mark Andrews wrote:
> > You don’t as Microsoft has not implemented TSIG.
>
> You could, perhaps, switch the Microsoft nameserver for BIND named.
>
> >> On 25 Nov 2019, at 18:52, Mundile  wrote:
> >
> >> How do I accomplish zone transfers (Master and Slave) between Master
> >> Linux Nameserver and Slave Windows 2016 Nameserver using TSIG Keys
>
> In that case (using BIND for Windows) it is simple, no different than
> TSIG from one Unix BIND to another.
>
> https://downloads.isc.org/isc/bind9/9.14.6/doc/arm/Bv9ARM.ch04.html#tsig
> ___
> Please visit https://lists.isc.org/mailman/listinfo/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: Zoneformat

[Kevin Darcy]

[ Classification Level: PUBLIC ]

It's not like "speed dialing" consists of prepending a bunch of
more-or-less arbitrary area codes and exchanges and hoping that eventually
you'll get the right combination of numbers to reach the intended
recipient. THAT would be the proper analogy for suffix-searching.

A better analogy of "speed dialing", in the TCP/IP context, would be
browser bookmarks and the like, i.e. a limited, simplified list of choices,
on the frontend, each of which translates to the appropriate protocol-
and/or technology-specific identifiers, on the backend. I don't have a
problem with app features that make people's lives more convenient, as long
as what ends up in the DNS ecosystem is an unambiguous FQDN.

As for addressing coworkers by their short names, that works and sometimes
doesn't. I once worked regularly with 5 people who all had the first name
"Matt" (now we're down to only 3 in our area :-)


   - Kevin

On Mon, Oct 28, 2019 at 6:02 PM Paul Kosinski via bind-users <
bind-users@lists.isc.org> wrote:

> "... long ago adapted to using full numbers, including area codes, for
> pretty much *all* phone dialing ..."
>
> Except that that proved to be so onerous that people often use "speed
> dialing" for commonly dialed numbers. (Not to mention the fact that
> people usually address their friends and coworkers by short names.)
>
>
> On Mon, 28 Oct 2019 12:19:35 -0400
> Kevin Darcy  wrote:
>
> > [ Classification Level: PUBLIC ]
> >
> > My opinion? It's better to wean your users away from shortnames than
> > to try to cobble together kludges, on the client side or the BIND
> > side, to support a bad habit. Shortnames introduce ambiguity, lead to
> > nasty surprises, are inefficient and insecure. Just like we (in the
> > U.S. at least) long ago adapted to using full numbers, including area
> > codes, for pretty much *all* phone dialing, people can adapt to using
> > FQDNs. They've already adapted to it, overwhelmingly, for Internet
> > web traffic (notwithstanding some "helpful" browsers that will tack
> > on "www" to the front of a shortname, and ".com" at the end, which is
> > often *not* what is wanted or safe). Why have a different user
> > experience, when on or off the enterprise network, a perimeter that
> > is quickly eroding? Just use FQDNs everywhere, keep it consistent.
> >
> > Anyway, that's my 2-cents, from someone who has been battling the
> > "shortname disease" for decades, with a substantial amount of
> > (although not perfect) success.
> >
> >
> >   - Kevin
> >
> > On Mon, Oct 28, 2019 at 8:56 AM MEjaz  wrote:
> >
> > > Noxexistent domain error .
> > >
> > > Here is my configuration.
> > > ===
> > >
> > > zone "crm365app" {
> > > type master;
> > > file "crm365app.cyberia.net.sa.hosts";
> > > allow-query {any;};
> > > };
> > >
> > >
> > > File
> > >
> > > 
> > > [root@ns1 ~]# cat  /var/named/crm365app.cyberia.net.sa.hosts
> > > $TTL 3600
> > > ;   Addresses and other host information
> > > ;
> > > ;
> > >
> > > @   IN  SOA ns1.cyberia.net.sa. root.cyberia.net.sa. (
> > > 2015034459 ; serial
> > > 43200   ; refresh every 12 hours
> > > 4320; retry after 1 hour
> > > 1209600  ; expire after 2 weeks
> > > 21600 )  ; minimum
> > >
> > > ; Define the name servers and mail servers
> > >
> > > IN  NS  ns1.cyberia.net.sa.
> > > IN  NS  ns2.cyberia.net.sa.
> > >
> > > IN  MX  10 smtp.cyberia.net.sa.
> > >
> > > ; Define localhost
> > > *INA   127.0.0.1
> > >
> > > ; Define hosts in this zone
> > >
> > >
> > > www IN  CNAME   webhost.cyberia.net.sa.
> > > crm365app   IN  A   212.71.33.252
> > >
> > > =zone file
> > > end=
> > >
> > > [root@ns1 named]# host crm365app
> > > Host crm365app not found: 3(NXDOMAIN)
> > >  [root@ns1 named]# named-checkzone crm365app
> > > crm365app.cyberia.net.sa.hosts
> > > zone crm365app/IN: loaded serial 2015034459
> > > OK
> > >
> > > -

Re: Zoneformat

[Kevin Darcy]

[ Classification Level: PUBLIC ]

My opinion? It's better to wean your users away from shortnames than to try
to cobble together kludges, on the client side or the BIND side, to support
a bad habit. Shortnames introduce ambiguity, lead to nasty surprises, are
inefficient and insecure. Just like we (in the U.S. at least) long ago
adapted to using full numbers, including area codes, for pretty much *all*
phone dialing, people can adapt to using FQDNs. They've already adapted to
it, overwhelmingly, for Internet web traffic (notwithstanding some
"helpful" browsers that will tack on "www" to the front of a shortname, and
".com" at the end, which is often *not* what is wanted or safe). Why have a
different user experience, when on or off the enterprise network, a
perimeter that is quickly eroding? Just use FQDNs everywhere, keep it
consistent.

Anyway, that's my 2-cents, from someone who has been battling the
"shortname disease" for decades, with a substantial amount of (although not
perfect) success.


  - Kevin

On Mon, Oct 28, 2019 at 8:56 AM MEjaz  wrote:

> Noxexistent domain error .
>
> Here is my configuration.
> ===
>
> zone "crm365app" {
> type master;
> file "crm365app.cyberia.net.sa.hosts";
> allow-query {any;};
> };
>
>
> File
>
> 
> [root@ns1 ~]# cat  /var/named/crm365app.cyberia.net.sa.hosts
> $TTL 3600
> ;   Addresses and other host information
> ;
> ;
>
> @   IN  SOA ns1.cyberia.net.sa. root.cyberia.net.sa. (
> 2015034459 ; serial
> 43200   ; refresh every 12 hours
> 4320; retry after 1 hour
> 1209600  ; expire after 2 weeks
> 21600 )  ; minimum
>
> ; Define the name servers and mail servers
>
> IN  NS  ns1.cyberia.net.sa.
> IN  NS  ns2.cyberia.net.sa.
>
> IN  MX  10 smtp.cyberia.net.sa.
>
> ; Define localhost
> *INA   127.0.0.1
>
> ; Define hosts in this zone
>
>
> www IN  CNAME   webhost.cyberia.net.sa.
> crm365app   IN  A   212.71.33.252
>
> =zone file
> end=
>
> [root@ns1 named]# host crm365app
> Host crm365app not found: 3(NXDOMAIN)
>  [root@ns1 named]# named-checkzone crm365app
> crm365app.cyberia.net.sa.hosts
> zone crm365app/IN: loaded serial 2015034459
> OK
>
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> Reindl Harald
> Sent: Monday, October 28, 2019 1:46 PM
> To: bind-users@lists.isc.org
> Subject: Re: Zoneformat
>
>
>
> Am 28.10.19 um 11:01 schrieb MEjaz:
> > *From:* MEjaz [mailto:me...@cyberia.net.sa]
> > *Sent:* Monday, October 28, 2019 10:27 AM
> > *To:* 'bind-users-boun...@lists.isc.org'
> > 
> > *Subject:* Zoneformat
> >
> > Is ther any way I can create the zone without the (.) I mean non fully
> > qualified domain name just as "example" instead "example.com"'
>
>
> what is the problem you try to solve?
> ___
> Please visit https://lists.isc.org/mailman/listinfo/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: Bind-Efficientip

[Kevin Darcy]

[ Classification Level: PUBLIC ]


It's not clear to me from the marketing fluff whether EfficientIP is based
on BIND or not.

If it is, then consider that you have an open-source codebase, and the
eternal debate is whether open source is inherently more secure or not. On
the one side, is the "many eyes makes all bugs shallow", i.e. more
visibility of the code means more likelihood of finding bugs. But, the bad
guys can see the code too. So then, you have to evaluate "after a bug is
found, how quickly can it be patched in all implementations which use that
codebase?".

If, on the other hand, the codebase is proprietary, there are more likely
to be bugs, undiscovered for longer. But, it's harder for the bad guys to
find. They have to use fuzzing, reverse engineering, etc. And then, do you
trust the company to actually *acknowledge* or *admit* that the bug exists,
if a "white hat" researcher finds it first. There have been many documented
cases, where vendors of proprietary software go into denial mode, even as
vulnerabilities are being actively exploited.

Beyond the DNS codebase itself, if there are other components to the
product suite -- and EfficientIP seems to have a wide portfolio; they're
not just a DNS/DHCP solution -- all of those components are potentially
vulnerable too. Web components can be subject to cross-site scripting,
database components to SQL injection and the like. But, many of the
EfficientIP components seem to *enhance* security too, whether it be more
visibility (feeding into a SIEM, presumably), DoS protection, etc. So you
have to weigh both the risks and the benefits.

Overall, from their marketing, their portfolio looks very similar to
Infoblox (which we use). Even down to the fact that they're positioning
themselves as a security hub. You might want to survey a number of
products, since there seems to be some convergence on this space. The
intersection between DNS/DHCP management solutions, and infosec, is not
just a niche any more.


 - Kevin

On Sun, Oct 20, 2019 at 9:19 AM MEjaz  wrote:

>
>
> Hello all,
>
>
>
>
>
> We are an leading ISP CYBERIA (www.cyberia.net.sa),  we are using bind
> since several years, and 1000  of zones are hosted in it. quite ok.
>
>
>
> As you know these days  there has been several security threats, So
> deciding to go with  *Efficient iP DDI and DNS Security Solution*
> https://www.efficientip.com/
>
>
>
> Therefore just wanted to know if anyone have any experience with
>  EfficientDNS, and at the same time wanted to know the major difference
> between the both..
>
>
>
> Please advise, Thanks in advance
>
>
>
> Thanks,
>
> Ejaz
>
> Asst. Operation Director of Systems.
>
> Cyberia SAUDI ARABIA
>
> P.O.Box: 301079, Riyadh 11372
>
> Phone:  (+966) 11 464 7114 Ext. 140
>
> Mobile:  (+966) 562311787
>
> Fax:  (+966) 11 465 4735
>
> Website: http://www.cyberia.net.sa
>
>
>
>
>
>
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/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: Proper Way to Configure a Domain which never sends emails

[Kevin Darcy]

[ Classification Level: PUBLIC ]

DNSBL is by IP, true, but there are other forms of "SMTP blacklist" that
are by domain. Getting one's domain on one or more of those lists would
help avoid the impact of someone trying to use the domain to spoof
malicious email. Sure, you could wait until *after* the damage is done, and
then the domain might end up on one or more blacklists, but I was just
musing, half humorously, on whether one could be proactive, by volunteering
to be on the list(s).

The OP specifically said he wanted to *receive* mail, so I don't understand
why people keep recommending a null MX.

I've concurred that a "-all" SPF will help.


   - Kevin

On Mon, Aug 19, 2019 at 8:07 PM Reindl Harald 
wrote:

>
>
> Am 19.08.19 um 23:31 schrieb Kevin Darcy:
> > [ Classification Level: PUBLIC ]
> >
> > MXes are for *receiving* mail of course. The request is about *sending*
> > mail.
> >
> > Setting the SPF record to "-all" is probably about the best you can do,
> > since AFAIK there is no universally-recognized way to signal "domain X
> > never sends mail".
> >
> > Ironically, in order to prevent anyone from accepting mail purportedly
> > from your domain, you might want to make yourself look as much as
> > possible like SPAM or malware.
> >
> > Perhaps you could volunteer your domain to be added to one or more of
> > the public SMTP blacklists? :-)
>
> DNSBL lists IP's not domains and so only you blacklist machones - that's
> the worst idea whan can have when nomailspf and null-mx are the way to go
>
> @  IN TXT  "v=spf1 -all"
> @  IN MX0  .
>
___
Please visit https://lists.isc.org/mailman/listinfo/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: Proper Way to Configure a Domain which never sends emails

[Kevin Darcy]

[ Classification Level: PUBLIC ]

MXes are for *receiving* mail of course. The request is about *sending*
mail.

Setting the SPF record to "-all" is probably about the best you can do,
since AFAIK there is no universally-recognized way to signal "domain X
never sends mail".

Ironically, in order to prevent anyone from accepting mail purportedly from
your domain, you might want to make yourself look as much as possible like
SPAM or malware.

Perhaps you could volunteer your domain to be added to one or more of the
public SMTP blacklists? :-)


 - Kevin

On Mon, Aug 19, 2019 at 10:34 AM Barry Margolin  wrote:

> In article ,
>  Ignacio García  wrote:
>
> > Hi there.
> >
> > Thanks for your support. First message to the list, sorry if already
> > posted a similar question, but I haven't found mention anywhere.
> >
> > I have to set up dns records for a domain just for a web site, for which
> > we will NEVER send emails (though we might receive some from old
> > customers), so I would like to announce somehow that emails sent from
> > this domain should always be disregarded. I was thinking of setting just
> > A and  records for @ and www, NS records, MA records (for receiving)
> > and SPF with a record just consisting of v=spf1 -all  , not declaring an
> > A and MX records at all. I'm not sure at all this is a proper way of
> > declaring this. In fact, what I would like is to EXPLICITELY mention
> > somehow that we will never send emails from that domain. Could anybody
> > help me with this?
>
> A common practice is to point the MX record to ".".
>
> --
> 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
>
___
Please visit https://lists.isc.org/mailman/listinfo/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: SERVFAIL when looking up TXT from particular domain

[Kevin Darcy]

There's a huge amount of DNSSEC verbiage in the response to that query
(4931-byte response from the authoritative nameservers), when querying
with +dnssec. I'm guessing the resolver function of BIND might be having
trouble with DNSSEC validation. At least, that's a hypothesis. I'm not
familiar enough with the current BIND code to confirm/deny it.

   - Kevin




On Wed, Jun 26, 2019 at 9:19 AM Dennis via bind-users <
bind-users@lists.isc.org> wrote:

> Hi List,
>
> When I try to resolve a TXT record cleanmail4.capgeminioutsourcing.nl
> I'll get a SERVFAIL. Asking Google seems to work though:
>
> rndc flush
>
> dig TXT cleanmail4.capgeminioutsourcing.nl @localhost
>
> ; <<>> DiG 9.10.3-P4-Debian <<>> TXT cleanmail4.capgeminioutsourcing.nl
> @localhost
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3652
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1024
> ;; QUESTION SECTION:
> ;cleanmail4.capgeminioutsourcing.nl. INTXT
>
> ;; Query time: 176 msec
> ;; SERVER: ::1#53(::1)
> ;; WHEN: Wed Jun 26 07:57:59 CDT 2019
> ;; MSG SIZE  rcvd: 63
>
> named -v
> BIND 9.10.3-P4-Debian 
>
> This shows up in the log:
>
> fetch completed at ../../../lib/dns/resolver.c:5082 for
> cleanmail4.capgeminioutsourcing.nl/TXT in 0.176478: ran out of
> space/success [domain:capgeminioutsourcing.nl
> ,referral:2,restart:1,qrysent:2,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
>
>
> BIND is running in a debian 9 VM in default config. I spun up that vm
> after we discovered a BIND machine elsewhere with the same problem.
>
> Google gives an answer:
>
> ; <<>> DiG 9.10.3-P4-Debian <<>> TXT cleanmail4.capgeminioutsourcing.nl @
> 8.8.8.8
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58950
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;cleanmail4.capgeminioutsourcing.nl. INTXT
>
> ;; AUTHORITY SECTION:
> capgeminioutsourcing.nl. 899INSOAns1.capgeminioutsourcing.nl.
> dns\.bnl.capgemini.com. 189324 28800 2880 2419200 900
>
> ;; Query time: 45 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Wed Jun 26 08:04:51 CDT 2019
> ;; MSG SIZE  rcvd: 124
>
> There is no record but Google does not fail. I've checked the SOA and can
> resolve the NS records. I'm overlooking something, but what?
>
>
>
> Cheers,
>
> Dennis
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/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: Change DNS records automatically when a link is DOWN

[Kevin Darcy]

Publish all 3 NSes.

Publish MX records with primary/failover preferencing.

Use a load-balancer (free or commercial, software/hardware/cloud-based) to
direct the web traffic.

 - Kevin

On Wed, Jun 5, 2019 at 11:16 AM Roberto Carna 
wrote:

> Dear people, I have two sites:
>
> - Main site with an Internet link and two BIND services (DNS1 y DNS2) and
> a /28 block, and web and mail services supported
> - Backup site with a second Internet link and a BIND service (DNS3) and
> another /28 block
>
> When the Internet link from main site is DOWN, the web and mail traffic
> come through the backup site to main site crossing a L2L. So I need to
> change the IP's of the FQDN hosts I have supported in the DNS3 in order to
> continue offering services (web and mail). How can I do this automatically?
> Is there any way that "something" monitors the main Internet link and in
> case it is DOWN automatically order to modify the FQDN records in DNS3 ???
>
> Thanks a lot and regards!!!
> ___
> Please visit https://lists.isc.org/mailman/listinfo/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: Forwarders with static-stub

[Kevin Darcy]

TBH, I haven't worked specifically with "static-stub", but with the classic
"stub", one would put a "null forwarders" statement in the zone definition
to inhibit forwarding.

I.e.

forwarders { };

   - Kevin

On Wed, May 22, 2019 at 8:16 AM Ben Lavender  wrote:

> Hi,
>
> When I setup static-stub zones with the global forwarders options
> configured, BIND by design forwards the requests before using the stubs.
>
> What is the best way around this so the stubs and cache are consulted
> first?
>
> This is required for split-brain DNS.
>
> Thanks
>
> Regards
>
> Ben Lavender
> ___
> Please visit https://lists.isc.org/mailman/listinfo/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: Enable recursive query for only a particular zone

[Kevin Darcy]

The simple answer is that you can do this with allow-recursion. Note that
"recursion no" is a big (instance-wide or view-wide) "off" switch for
recursion, so if you already have that set, you'll have to un-set it in
order to apply your allow-recursion controls in a granular fashion. You may
also want to consider your allow-query-cache controls because, even if a
given client isn't allowed to recurse for a given query, the operation of
fetching something that is resident in the cache -- put there as a result
of the query of some other client (which *was* allowed to recurse) -- isn't
considered to require "recursion", per se, but you probably don't want
arbitrary clients sniffing around at what's in your cache. (If one has
separate views, or separate instances, for resolving versus hosting, then
this sort of thing isn't an issue, but it sounds like you're trying to keep
everything in a single view).

The longer answer: you can use allow-recursion (with the caveats listed
above), but it may not achieve the result you're trying to achieve,
depending on what exactly that is. Enabling part of your namespace for
recursion doesn't *automatically* make it a sort of "proxy" for any names
that are queried within that part of the namespace. The crucial question to
ask is: will the incoming queries be requesting recursion or not? Normally,
when an iterative resolver follows the delegation hierarchy down from the
root, it's sending *non-recursion-desired* (RD=0) queries. If they follow
that delegation hierarchy down to your "special" zone, then even though you
may have enabled recursion for it, you'll never *provide* recursion, if it
isn't asked for (RD=0 means the requester doesn't want recursion performed,
even if recursion is available from the responder). The only way this works
is if the requester *explicitly* configures that part of that namespace (or
potentially, higher up in the hierarchy) to use your nameserver
recursively, e.g. by defining a zone of type "forward". This is not
reasonable to expect the Internet-as-a-whole to configure; it really only
works if you have a select community of devices and enough administrative
control to be able to maintain their DNS forwarding configuration(s).

So, depending on your use case, the solution you've hit upon -- enabling
recursion selectively for part of a namespace -- may not solve the
challenge you're trying to solve. Perhaps if you could elaborate a little
more on your situation, a more appropriate solution can be found.


  - Kevin


On Tue, May 7, 2019 at 3:05 AM Burn Zero  wrote:

> Hi,
>
> Is there a possibility to have recursion enabled only for one zone ( sub
> domain of a authoritative zone ) ? Is there any other way other than using
> view?
>
> Thank you
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/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 with zone delegation with private gTLD

[Kevin Darcy]

If you're doing stuff at really small scale, you can just define your own
root zone and put all of the records into it, including records in the
"phishing" subdomain, and any reverse records you care about (in the
"in-addr.arpa" and/or "ip6.arpa" subdomains). For that matter, if you only
have 1 BIND instance, you don't need to worry about recursion or
master/slave replication. BIND might complain if you only have 1 NS record
associated with a given zone name (since the standard says a minimum of 2),
but you could just make up a fictitious nameserver with a fictitious
address, and BIND will quickly figure out that it doesn't exist and stop
trying to use it.


 - Kevin

On Mon, Apr 8, 2019 at 5:51 AM Karl Lovink via bind-users <
bind-users@lists.isc.org> wrote:

> Hello,
> I am trying to set up a private gTLD with BIND9 and underneath that gTLD
> a subdomain. The subdomain runs on another BIND9 server.
>
> The problem I'am facing is that the BIND9 server of the gTLD gives a
> NXDOMAIN
> for the ns record of the subdomain. If have no clue what is wrong.
>
> Can somebody point me out what is wrong in my configuration.
>
> named.conf snippet
> view "phishing" {
> match-clients { phishing_net; };
> recursion yes;
>
> zone "lab" {
> type master;
> file "/etc/bind/gTLD/lab";
> };
> };
>
> gTLD lab zone:
> $TTL 60 ; TTL 60 seconds
> $ORIGIN lab.
> @   IN  SOA vdns01.lab. hostmaster.vdns01.mgmt.lab. (
> 2019040801
> 10800
> 3600
> 604800
> 38400 )
>
> IN  NS  vdns01.lab.
> IN  MX  mail.lab.
>
> vdns01  IN  A   192.168.111.200
> mailIN  A   192.168.10.103
>
> $ORIGIN acme.lab.
> @   IN  NS  ns1.acme.lab.
> IN  NS  vdns01.lab.
> ns1.acme.lab.   IN  A   192.168.10.42
>
>
>
> Greetz,
> Karl
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/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: Combining forward with master zone.

[Kevin Darcy]

Delegate needs.example.com from example.com and you should be set.


   - Kevin

On Wed, Feb 20, 2019 at 3:40 PM King, Harold Clyde (Hal) 
wrote:

> Could I just define needs.example.com as a zone in a separate file so:
>
>
>
> zone "example.com" { type master; notify no; file "static/antiphish.db";
> };
>
> zone "needs.example.com" { type forward; forwards{8.8.8.8;};
>
>
>
>
>
> --
>
> Hal
>
>
>
>
> 
>
> We have a URL phishing setup that causes URLs we detect to redirect to a
> warning page. We have run into a problem. One of our clients has scripts
> that he calls from a host in that domain.
>
> Needs.example.com when we block example.com.
>
> Can I create a root zone to define a wildcard pointing to our warning page
> with one hostname defined going to a forward’ed DNS source? I could just
> give it an IP, but can I forward that one domain to outside DNS (Google or
> their NS repository)?
>
>
>
> Here’s a very rough draft of the root zone:
>
>
>
> $ORIGIN .
>
> $TTL 3600
>
> example.com  IN SOA   us.ourdns.com.  helpdesk.ourdns.com.
>
>
>
> *CNAME  url-blocking.ourdns.com
>
> needsforward(8.8.8.8)
>
>
>
> --
>
> Hal
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/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: Combining forward with master zone.

[Kevin Darcy]

As discussed in another thread, delegate the zone you want to forward, in
addition to defining the zone as "type forward". If you already tried a
"type forward" and it didn't work, it was probably because the delegation
was missing. It's a non-obvious requirement, but named needs to see the
zone cut.


  - Kevin

On Wed, Feb 20, 2019 at 3:19 PM King, Harold Clyde (Hal) 
wrote:

> We have a URL phishing setup that causes URLs we detect to redirect to a
> warning page. We have run into a problem. One of our clients has scripts
> that he calls from a host in that domain.
>
> Needs.example.com when we block example.com.
>
> Can I create a root zone to define a wildcard pointing to our warning page
> with one hostname defined going to a forward’ed DNS source? I could just
> give it an IP, but can I forward that one domain to outside DNS (Google or
> their NS repository)?
>
>
>
> Here’s a very rough draft of the root zone:
>
>
>
> $ORIGIN .
>
> $TTL 3600
>
> example.com  IN SOA   us.ourdns.com.  helpdesk.ourdns.com.
>
>
>
> *CNAME  url-blocking.ourdns.com
>
> needsforward(8.8.8.8)
>
>
>
> --
>
> Hal
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/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:

[Kevin Darcy]

"type master".

It must contain the mandatory records that all zones require -- exactly 1
SOA and at least 2 NSes. You'll need some A/ records to resolve the NS
names into addresses. What the NSes point to is pretty much irrelevant, if
all of your clients are stub resolvers and only look up leaf records (A,
, MX, etc.)

For the teamviewer.com delegation, you'll need at least 2 NSes, but you can
point those to the same names as the apex NSes, if you wish. That would
save you from having to populate more A/ records in the zone.

If you haven't created a master file before, you might want to study up.
There are a few rules that need to be followed, and certain mistakes to be
avoided (although, for the root zone, the most common mistake -- failure to
dot-terminate names -- tends to be a non-issue :-)


 - Kevin

On Wed, Feb 20, 2019 at 8:49 AM Roberto Carna 
wrote:

> Dear Crist, sorry but I can understand at all what you say.please I
> ned to ask you again:
>
> You tell me to do this:
>
> zone "." {
> type master;
> file "empty.db";
> };
>
> The root zone Is "type master"  or "type hint" ???
>
> The empty.db is really an empty file with no data at all ???
>
> And where do I have to put my current file:
>
> recursion yes;
> zone "teamviewer.com" {
> type forward;
> forwarders { 8.8.8.8; };
> };
>
> Thanks in advance, I'll be waiting for your response please.
>
> Greetings!!!
>
> El mié., 20 feb. 2019 a las 0:57, Crist Clark ()
> escribió:
>
>> You need to explicitly define the root zone. Last I knew, BIND still
>> gets the root zone hardcoded into the executable and will try to Do
>> the Right Thing and find the root on its own even if the administrator
>> does not define one or provide hints.
>>
>> You need something like,
>>
>> zone "." {
>> type master;
>> file "empty.db";
>> };
>>
>>
>> On Tue, Feb 19, 2019 at 10:29 AM Roberto Carna 
>> wrote:
>> >
>> > Dear Matus and Kevin, please tell me if it's OK if I do thsi:
>> >
>> > named.conf:
>> > include "/etc/bind/named.conf.default-zones";
>> >
>> > named.conf.default-zones:
>> > recursion yes;
>> > zone "teamviewer.com" {
>> > type forward;
>> > forwarders { 8.8.8.8; };
>> > };
>> >
>> > named.conf.local:
>> > 
>> >
>> > I define "recursion yes" in named.conf.default-zones.
>> >
>> > Thanks again, regards !!!
>> >
>> > El mar., 19 feb. 2019 a las 15:13, Matus UHLAR - fantomas via
>> bind-users () escribió:
>> >>
>> >> On 19.02.19 09:45, Roberto Carna wrote:
>> >> >Dear Kevin, I am sorry but I didn't see your past response.
>> >> >
>> >> >Please can you show me with an example what you say: "Define root
>> zone.
>> >> >Delegate teamviewer.com from root. Define teamviewer.com as 'type
>> forward'".
>> >> >
>> >> >An also what is the benefit in defining a root zone with the
>> teamviewer.com
>> >> >delegated into it??? Because I put to work this zone just as a forward
>> >> >zone, without a root zone definition.
>> >>
>> >> the benefit is it does exactly what you want.
>> >> the "teamviewer.com" zone of type forward causes DNS resolution of
>> teamviewer.com
>> >> domain.
>> >> the root zone effectively disables everything else (because bind thinks
>> >> nothing else exists).
>> >>
>> >> >El lun., 18 feb. 2019 a las 17:00, Kevin Darcy (<
>> kevin.da...@fcagroup.com>)
>> >> >escribió:
>> >> >
>> >> >> I've already posted a solution for this. Basically, "Define root
>> zone.
>> >> >> Delegate teamviewer.com from root zone. Define teamviewer.com as
>> 'type
>> >> >> forward'".
>> >> >>
>> >> >> "Recursion yes" is implied. No views necessary. It doesn't make any
>> sense
>> >> >> anyway, to have the same match-clients list for all of one's views,
>> since
>> >> >> the first one matched is the one that's used.
>> >> >>
>> >> >> Did you not see my response, or did you perhaps dislike the
>> approach I
>> >> >> suggested?
>> >> >>
>> >> >> Ther

Re: DNS load balancing: UDP or TCP ?

[Kevin Darcy]

If you go with Anycast via BGP, make sure your network infrastructure has
"multipath" enabled, otherwise the traffic will be skewed to one node or
the other.
https://tools.ietf.org/id/draft-lapukhov-bgp-ecmp-considerations-01.html is
one source which summarizes some of the literature and standards on the
subject.


- Kevin

On Tue, Feb 19, 2019 at 2:01 PM Josh Kuo  wrote:

> Agree with Tony on TCP not going to be tried. Have you looked at using
> anycast? It is not true load balancing but it allows you to stand up
> multiple DNS servers that “shares” a single IP address.
>
> On Wed, Feb 20, 2019 at 12:25 AM Tony Finch  wrote:
>
>> Roberto Carna  wrote:
>>
>> > Dear, I have to balance two DNS servers for a special reason.
>>
>> https://www.powerdns.com/dnsdist.html
>>
>> > The DNS clients are a mix of Windows, Cisco and Linux machines, so I
>> > think they ask for a FQDN using UDP and after that -if there is no
>> > response-, they ask the same FQDN using TCP, and so the load balancing
>> > will be succesful.
>>
>> No, fallback to TCP relies on receiving a truncated UDP response. You
>> never want a DNS client to be waiting around for a response that will
>> not arrive.
>>
>> Tony.
>> --
>> f.anthony.n.finchhttp://dotat.at/
>> Rockall, Malin: Southeast veering southwest 6 to gale 8, occasionally 5
>> later.
>> Rough or very rough. Rain. Moderate or 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
> 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: Malicious-DNS

[Kevin Darcy]

Another approach is to define a "fake" vitaminc.pro domain, point it at an
internal webserver (assuming you have a spare, or can spin one up for the
purpose), and see what clients are hitting it.

Of course, that assumes the communication is web-based. If it's some other
protocol(s), you'd need to monitor that protocol, or those protocols, on
the "decoy" server. One would need to know more about the behavior of the
malware involved.

Speaking of which, Virustotal doesn't seem to think there's anything
suspicious about vitaminc.pro. Haven't checked my other sources of Threat
Intelligence, but usually there's *something* on VT if a domain is being
used as a C


 - Kevin


On Mon, Feb 18, 2019 at 9:24 AM Tony Finch  wrote:

> MEjaz  wrote:
> >
> > If I enabled the system performs will slow down?
>
> Depends on how much load your servers are under and what their capacity
> is.
>
> An alternative to query logs, when you are searching for a known query
> name, is to use tcpdump. It's a tedious and fiddly to convert the name to
> DNS wire format and then into a pcap filter expression, so I have a little
> script to do that (quoted below after my .sig). The command you want is
> like:
>
> tcpdump -np udp port 53 and '(' udp[20] == 8 and udp[21] == 118 and
> udp[22] == 105 and udp[23] == 116 and udp[24] == 97 and udp[25] == 109 and
> udp[26] == 105 and udp[27] == 110 and udp[28] == 99 and udp[29] == 3 and
> udp[30] == 112 and udp[31] == 114 and udp[32] == 111 ')'
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Southeast Iceland: Northerly 6 to gale 8, veering northeasterly 5 to 7.
> Rough
> or very rough. Rain or wintry showers. Good, occasionally poor.
>
>
> #!/usr/bin/perl
>
> use warnings;
> use strict;
>
> use Net::DNS::DomainName;
>
> die "usage: $0 \n"
> unless @ARGV == 1;
>
> my $text = shift;
> my $wire = new Net::DNS::DomainName($text)->canonical;
>
> my @wire = unpack 'C*', $wire;
>
> pop @wire unless $text =~ m{\.$};
>
> printf "'(' %s ')'\n",
> join ' and ',
> map { sprintf "udp[%d] == %d",
>   20 + $_, $wire[$_] }
> 0 .. $#wire;
> #!/usr/bin/perl
>
> use warnings;
> use strict;
>
> die "usage: tcpdump-qname.pl \n"
> unless @ARGV == 1;
>
> my $name = shift;
>
> my @name = unpack 'C*', $name;
>
> printf "%s\n", join ', ', @name;
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/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:

[Kevin Darcy]

I've already posted a solution for this. Basically, "Define root zone.
Delegate teamviewer.com from root zone. Define teamviewer.com as 'type
forward'".

"Recursion yes" is implied. No views necessary. It doesn't make any sense
anyway, to have the same match-clients list for all of one's views, since
the first one matched is the one that's used.

Did you not see my response, or did you perhaps dislike the approach I
suggested?

There was some subsequent discussion about not relying on DNS resolution as
one's *only* control over what sites one's clients can or cannot access.
While I agree with that, my position is that there's nothing wrong with
controlling DNS resolution, in addition to other controls.

  - Kevin

On Mon, Feb 18, 2019 at 10:44 AM Roberto Carna 
wrote:

> Dear I've implemented two views, one for local resolution and the other
> for forward a public zone to our resolver.
>
> But now I have a problem:
>
> If I define the same clients for the local zone view and forward view,
> depending on the order of the views the client can resolve or not the
> query. In this case client 10.12.1.1 will match view INT and not view EXT:
>
> acl internal { 10.12.1. 1; };
> acl external { 10.12.1.1; };
>
> view "INT" {
> match-clients { internal; };
> recursion no;
> zone "company.com" {
> type master;
> file "/etc/bind/zones/company.com.db";
> };
>
> view "EXT" {
> match-clients { external; };
> recursion yes;
> zone "teamviewer.com" {
> type forward;
> forward only;
> forwarders {
> 172.1 8.1.1;
> };
> };
>
> If I define just one view with local and forward zones, I have to define
> "recursion yes" because the forward zone need this option, but in this case
> a query for a local zone is trying to be resolved against ROOT Servers and
> finally against master zone but it takes some seconds:
>
> acl unique { 10.12.1. 1; };
>
> view "INT-EXT" {
> match-clients { unique; };
> recursion yes;
> zone "company.com" {
> type master;
> file "/etc/bind/zones/company.com.db";
> };
> zone "teamviewer.com" {
> type forward;
> forward only;
> forwarders {
> 172.1 8.1.1;
> };
> };
>
> How can I define same clients to try resolving first view and -if there is
> no response- they try with second view ???
>
> Or is there any other way to do what I want?
>
> Regards
> ___
> Please visit https://lists.isc.org/mailman/listinfo/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: Forward zone inside a view

[Kevin Darcy]

Controlling DNS resolution isn't the panacea for all security challenges,
but then neither is a firewall. Or IPS. Or DLP. Or
blacklisting/whitelisting. Or restrictive routing. Or NAT'ing. But some
combination of those can be part of an overall security strategy. Defense
in depth.


- Kevin

On Tue, Feb 12, 2019 at 6:34 PM Timothe Litt  wrote:

> All these replies are correct in the details (as usual), but miss the
> point.
>
> Blocking name resolution, while popular, does not meet the OP's
> requirement:
>
> "The point is I have several desktops that *must* have access **only** to
> internal domains.*"
>
> Let's say that your client's favorite illicit site is facebook.com.
>
> One dig (or host) command reveals that:
>
>   facebook.com has address 157.240.3.35
>  facebook.com has IPv6 address 2a03:2880:f101:83:face:b00c:0:25de
>
> Fits on scrap of paper.  Carry in to office.  Connect - with a Host header
> for http, SNI for TLS, and off you go.  Or just put it in hosts.txt/hosts.
>
> Or use a public nameserver.   Or...
>
> If you want to block access, you need a firewall.  If you merely want to
> inconvenience people or reduce the risk of clicking on ransomware
> hyperlinks, mess with their default nameserver.  RPZ is good for that.  If
> you have a private address space & need to resolve some names differently
> inside and out, views are good for that. (Or you can have a different
> nameserver; tastes vary.)  If you are resource limited and want to benefit
> from a public server's larger cache, while serving authoritatively some
> local names, forwarding can be a good choice.
>
> But "**must** have access **only**" implies that one expects that the
> solution should resist *more* than a cooperative or unmotivated client.  NO
> DNS-only based solution will do that.
>
> Governments and political pressure groups think that DNS corruption is an
> effective tool for limiting access.  People here know better.  It deters
> certain casual problem behavior.  It does not prevent anyone with a modicum
> of knowledge and determination from watching cat videos.  (Or downloading
> malware, or whatever other behavior a policy maker wishes to ban.)
>
> It is worth listening to the OP's problem statement and steering him away
> from illusory technology.  It's the responsible thing to do.
>
> That there are technical answers to the question asked doesn't mean that
> it's the right question.  If it's not (and in this case it does not appear
> to be), those answers are not helpful.  Even though they are correct in
> other contexts.
>
>
> Timothe Litt
> ACM Distinguished Engineer
> --
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed.
>
> On 12-Feb-19 17:45, Kevin Darcy wrote:
>
>
> Define root zone.
>
> Delegate teamviewer.com from root zone.
>
> Define teamviewer.com as "type forward".
>
> "recursion no" is incompatible with *any* type of forwarding or iterative
> resolution. Should only be used if *everything* you resolve is from
> authoritative data, i.e. for a hosting-only BIND instance. Since you want
> to forward -- selectively -- you need "recursion yes". Nothing outside of
> that part of the namespace will be forwarded, since named considers
> everything else to be contained in the root zone.
>
>
>   - Kevin
>
> On Mon, Feb 11, 2019 at 9:06 AM Roberto Carna 
> wrote:
>
>> Matus, I've followed whatyou say:
>>
>> view "internet" {
>>match-clients { internet_clients; key "pnet"; };
>>
>> recursion yes;
>>
>> zone "teamviewer.com" {
>> type forward;
>> forward only;
>> forwarders {
>> 8.8.8.8;
>> };
>> };
>>
>> };
>>
>> but clients can resolve ANY public Internet domain, in addition to
>> teamviewer.comI think "recursion yes" apply to every public domain and
>> not just for "teamviewer.com", but I don't know why.
>>
>> Please can yoy give me more details, using forward or not, how can let
>> some clients resolve just teamviewer.com ??? I confirm that my BIND is
>> an authorittaive name server for internal domains.
>>
>> Thanks a lot again.
>>
>> El lun., 11 feb. 2019 a las 10:49, Matus UHLAR - fantomas (<
>> uh...@fantomas.sk>) escribió:
>>
>>> On 11.02.19 10:38, Roberto Carna wrote:
>>> >Dear Mathus, thanks al lot for your help.
>>> >
>>> >>> what is the point of running DNS server with only two hostnames
>>

Re: Forward zone inside a view

[Kevin Darcy]

Define root zone.

Delegate teamviewer.com from root zone.

Define teamviewer.com as "type forward".

"recursion no" is incompatible with *any* type of forwarding or iterative
resolution. Should only be used if *everything* you resolve is from
authoritative data, i.e. for a hosting-only BIND instance. Since you want
to forward -- selectively -- you need "recursion yes". Nothing outside of
that part of the namespace will be forwarded, since named considers
everything else to be contained in the root zone.


- Kevin

On Mon, Feb 11, 2019 at 9:06 AM Roberto Carna 
wrote:

> Matus, I've followed whatyou say:
>
> view "internet" {
>match-clients { internet_clients; key "pnet"; };
>
> recursion yes;
>
> zone "teamviewer.com" {
> type forward;
> forward only;
> forwarders {
> 8.8.8.8;
> };
> };
>
> };
>
> but clients can resolve ANY public Internet domain, in addition to
> teamviewer.comI think "recursion yes" apply to every public domain and
> not just for "teamviewer.com", but I don't know why.
>
> Please can yoy give me more details, using forward or not, how can let
> some clients resolve just teamviewer.com ??? I confirm that my BIND is an
> authorittaive name server for internal domains.
>
> Thanks a lot again.
>
> El lun., 11 feb. 2019 a las 10:49, Matus UHLAR - fantomas (<
> uh...@fantomas.sk>) escribió:
>
>> On 11.02.19 10:38, Roberto Carna wrote:
>> >Dear Mathus, thanks al lot for your help.
>> >
>> >>> what is the point of running DNS server with only two hostnames
>> allowed
>> >>> to resolve?
>> >
>> >The point is I have several desktops that must have access only to
>> internal
>> >domains. The unique exception is they have access to teamviewer.com  in
>> >order to download the Teamviewer client and a pair of operations in this
>> >public domain.
>>
>> if you disable recursion, any client using that server will only have
>> access
>> to the domains that are configured on that server internally.
>>
>> That also means they won't be allowed to contact any internal domains,
>> unless you configure those internal domains on that server.
>> Also no windows updates, nothing.
>>
>> >I think if I have setup "recursion = no", if I define a forward zone with
>> >"type forward" and the corresponding forwarder, this option enable the
>> >recursion just for this defined zone.
>>
>> No. Forward zone means recursion. "recursion no" is designed for
>> authoritative servers, not servers like there.
>>
>> >In general, my question is how to forward a public domain to a DNS
>> resolver
>> >like 8.8.8.8 ???
>>
>> configure it as "type forward" and forwarders to 8.8.8.8. However, BIND
>> can
>> do resolution well without forwarding. Also, this seems to be just the
>> opposite wht you describe above.
>>
>> >El sáb., 9 feb. 2019 a las 12:28, Matus UHLAR - fantomas (<
>> uh...@fantomas.sk>)
>> >escribió:
>> >
>> >> On 07.02.19 16:30, Roberto Carna wrote:
>> >> >Desktops I mentioned can only access to web apps from internal
>> domains,
>> >> but
>> >> >in some web apps there are links to download Teamviewer client
>> software
>> >> >from Internet. I can create a private zone "teamviewer.com" with all
>> the
>> >> >hostnames and IP's we will use, but if they change I will be in
>> trouble.
>> >> >
>> >> >So we need to forward the query to our resolvers in order to get a
>> valid
>> >> >response.
>> >> >
>> >> >So I think we can use the forward option from BIND, but it doesn't
>> work at
>> >> >all as I described:
>> >> >
>> >> >1. "recursion no" can only be set at the top (view) level, not
>> overridden
>> >> >   at the zone level.
>> >> >
>> >> >2. If I set "recursion no" at the view level, then a "type forward"
>> >> >   zone has no effect:
>> >> >
>> >> >  view "foo" {
>> >> >recursion no;
>> >> >...
>> >> >zone "teamviewer.com" {
>> >> >  type forward;
>> >> >  forward only;
>> >> >  forwarders {172.18.1.1; 172.18.1.2;};
>> >> >};
>> >> >
>> >> >-- query for foo.teamviewer.com fails and tell it's not a recursive
>> query
>> >>
>> >> the whole point of "recursion no" is not to answer recursive queries,
>> >> so there should be no wonder it works that way.
>> >>
>> >>
>> >> >3. If I define "recursion yes" at view level:
>> >> >
>> >> >  view "foo" {
>> >> >recursion yes;
>> >> >...
>> >> >zone "teamviewer.com" {
>> >> >  type forward;
>> >> >  forward only;
>> >> >  forwarders {172.18.1.1; 172.18.1.2;};
>> >> >};
>> >> >
>> >> >-- query for foo.teamviewer.com is OK, but also I get response OK
>> from
>> >> >foo.ibm.com, foo.google.com, and any other public domain from
>> Internet
>> >> >(and this is not what I want, it's what I'm trying to prevent))
>> >> >
>> >> >So can you help me please???
>> >>
>> >> you still have not answered my question:
>> >>
>> >> >> what is the point of running DNS server with only two hostnames
>> allowed
>> >> to
>> >> >> resolve?
>> >>
>> >> However, you can define empty type 

Re: BIND DNS Enable audit logs - Authoritative

[Kevin Darcy]

I don't believe there is any logging category for this, even when zones are
enabled for Dynamic Update, in which case the versioning is done
automatically. There used to be a "journalprint" utility that one could run
against the .jnl files to show the update history. But, even if the
journaling mechanism and the "journalprint" utility still exist as I
remember it, it would most likely only work for Dynamic-Update-enabled
zones. I don't believe .jnl files are created for
non-Dynamic-Update-enabled zones, although I could be wrong on that --
maybe named synthesizes .jnl files for purposes of IXFR (???).

If you're doing manual editing, I assume you have some mechanism to reload
the zone after each edit, presumably a script of some sort. The best
suggestion I have, short of evolving your solution significantly, is to add
a "diff against previous version" + "make a copy of the current version of
the file" sequence into that script, to capture the deltas, along with a
decision on how much history you want to keep, and perhaps a cron script to
purge the stale versions so the repository doesn't grow without bound. (The
maintenance/garbage-collection function could theoretically be integrated
into the main diff logic).

The next evolution might be to use a version-control system. The next
evolution beyond that might be a web interface with a dynamic-update
backend (which still serves some of our use cases) or a "panel" package
(assuming it has sufficient logging/auditing for your needs) or an
enterprise-strength DNS management solution (e.g. Infoblox, which we also
use).


- Kevin

On Fri, Jan 11, 2019 at 9:50 AM Daniel Dawalibi 
wrote:

> Hello
>
> We edit our zones manually (not through panel interface), is it possible to
> log DNS updates in this case?
> Logging is already enabled but we are unable to track the updated zones in
> the logs
> The enabled category on the authoritative Master DNS server  are "xfer-in",
> "security", "network", "default", "config", "queries" and "update".
>
> How can we enable the journal files in our case? Is there any impact on the
> DNS performance?
>
>
> Regards
> Daniel
>
> -Original Message-
> From: Tony Finch [mailto:d...@dotat.at]
> Sent: Tuesday, January 8, 2019 2:05 PM
> To: Daniel Dawalibi
> Cc: bind-users@lists.isc.org
> Subject: Re: BIND DNS Enable audit logs - Authoritative
> Importance: High
>
> Daniel Dawalibi  wrote:
> >
> > Is it possible to enable the audit logs on BIND DNS so we can track
> > changes performed on the DNS records level (Add/Delete/Modify A,MX,NS,.
> records)?
>
> You can get that by default, depending on how the changes were performed.
>
> If you use `nsupdate` or some other dynamic DNS UPDATE client, `named` will
> log changes like this ...
>
> 08-Jan-2019 11:55:09.826 update: info:
> client @0x55b747f47ec0 ::1#5685/key local-ddns:
> updating zone 'private.cam.ac.uk/IN':
> adding an RR at 'private.cam.ac.uk' SOA primary.dns.cam.ac.uk.
> hostmaster.cam.ac.uk. 1546948509 1800 900 604800 3600
> 08-Jan-2019 11:55:09.826 update: info:
> client @0x55b747f47ec0 ::1#5685/key local-ddns:
> updating zone 'private.cam.ac.uk/IN':
> adding an RR at '.lcil.private.cam.ac.uk' A 172.22.QQ.QQ
>
> The changes are also recorded in the zone's journal, which you can extract
> like:
>
> $ named-journalprint /home/named/zone/private.cam.ac.uk.jnl
> [...]
> del private.cam.ac.uk.  3600IN  SOA primary.dns.cam.ac.uk.
> hostmaster.cam.ac.uk. 1546944908 1800 900 604800 3600
> add private.cam.ac.uk.  3600IN  SOA primary.dns.cam.ac.uk.
> hostmaster.cam.ac.uk. 1546948509 1800 900 604800 3600
> add .lcil.private.cam.ac.uk. 3600 INA   172.22.QQ.QQ
>
> You might want to use the `ixfr-from-differences` and `max-journal-size`
> options if you care about preserving journal contents.
>
> Alternatively, keep your zone contents in `git` or a database that keeps an
> audit log :-)
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/ Mull of Galloway to
> Mull
> of Kintyre including the Firth of Clyde and North
> Channel: Northwesterly 4 or 5, occasionally 6 at first in the North
> Channel,
> becoming variable 3 or less. Moderate, becoming smooth or slight.
> Occasional
> rain later. Good, occasionally moderate 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
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: dns cache issue

[Kevin Darcy]

Offhand, sounds like your LAN is saturated so the queries might not be
getting to BIND in the first place. Or the replies aren't getting back.
It's unlikely that QoS is going to help this, you indicated that QoS was on
your "router", and that is typical -- usually QoS is found on WAN links.
(Although, on the other hand, you mentioned VoIP, and VoIP sometimes
requires applying QoS at the LAN level too).

You currently have query logging turned off. If it's not too
resource-intensive, you might want to consider turning that on, to verify
whether the queries are getting to BIND. Or, run a packet capture on the
BIND side. Packet capture on the BIND device should also help to identify
any issues talking upstream (e.g. to TLD servers or auth servers for
domains like google.com). Packet capture on the *client* side would
probably be necessary for definitive proof of whether replies are being
dropped by the LAN (compare what the server sent side-by-side with what the
client saw).

I was intrigued by "server fe80::/16 { bogus yes; }; " in your config. Have
you had issues with IPv6 link-local addresses being associated with
delegated nameservers? I haven't noticed this, but then again, I haven't
been looking for that particular misconfiguration specifically...


- Kevin



On Thu, Jan 10, 2019 at 12:06 AM Edwardo Garcia  wrote:

> With new windows update last day, we notice something strange, our local
> DNS cache server timeout on lookups.
>
> For example lookup google.com, 1 minute later fails timeout looking up,
> but since it has already looked it up it should have returned answer from
> cache yes? google has a 5min TTL, my cache doesnt cacher it for even  1ns
> it seems
>
> QoS on router gives DNS (udp and tcp)and VoIP highest priority, everything
> else is default QoS must be working because if I do
> host www.google.com $externalDNSserver   I get an answer pretty much
> right away,  immediately try again on our local dns server it times out
> cant connect to any servers.
> this contrinues on, if I drop the LAN port on switch the windows update
> machine uses,  it resolves google.com again, bring back up that port, it
> times out again.
>
> this only happens on congestion, with our cable link maxed out.
>
> (never thought i'd see the day when a windows pc would take out an entire
> network)
>
> Below is my named.conf I have to be missing something ?
>
> BIND 9.11.2-P1
> running on Linux i686 3.16.58 #1 SMP Sat Sep 29 11:06:24 AEST 2018
> built by make with defaults
>
> acl "trusted" { localhost; 198.162.100.0/24; };
> acl "sysop" { localhost; 192.168.100.6; };
>
> options {
> directory "/var/named";
> allow-query { trusted; };
> allow-query-cache { trusted; };
> allow-transfer { sysop; };
> transfer-format many-answers;
> masterfile-format text;
> interface-interval 0;
> response-policy {zone "rpz.lan"; };
> dnssec-enable yes;
> dnssec-validation auto;
> empty-zones-enable yes;
> };
>
> server fe80::/16 { bogus yes; };
>
> logging {
> category lame-servers { null; };
> category edns-disabled { null; };
> category client { null; };
> category dnssec { null; };
>  //channel log_queries { file "/var/named/query.log";
> print-category yes; };
>  //category queries { log_queries; };
> channel log-rpz { file "/var/log/rpz.log" versions 10 25m;
> severity info; };
> category rpz { log-rpz; };
> };
>
> zone "." {
> type hint;
> file "root.cache";
>
> zone "rpz.lan" {
> type master;
> file "rpz.lan";
> allow-query { trusted; };
> allow-update {none;};
> notify no;
> };
>
>
> zone "akamai.net" {
> type forward;
> forward first;
> forwarders { xx; xx; };
> };
>
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/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: one-zone-only forwarding DNS

[Kevin Darcy]

9.5.5 is old -- upgrade.

But, to the architecture issue... sounds like you need an "internal root
with forwarding exceptions" setup.

   - As per best practices, consider separating the recursive-resolver and
   hosting functions into separate views, separate named instances (listening
   on different IPs) or even separate server instances.
   - If you opt *not* to make such a separation, then at the very least,
   you'll need to replace "recursion no" with "allow-recursion", permitting
   localhost and internal clients. In the absence of recursion being allowed,
   none of your "type forward" zone definitions are going to work.
   - Define an internal root zone that contains delegations for the parts
   of the namespace that you want to resolve for your internal clients, either
   from authoritative data or via forwarding. Being delegated allows
   non-authoritative parts of the namespace to resolve sanely, via "type
   forward" (aka selective or conditional forwarding) definitions in
   named.conf. Queries for anything that doesn't fall under a delegation gets
   NXDOMAIN from your internal root zone, which I believe meets your
   requirements. Note that selective/conditional forwarding is for a whole
   branch of the namespace -- if you want to carve out some parts of a
   namespace that are forwarded, and others that aren't, or if the delegation
   hierarchy seen through forwarding differs from the structure you want
   internally, then it gets complicated, but I won't belabor the point here,
   since I don't know if you have such a requirement or not. Note also that
   when running an internal root, you'll need to make arrangements for reverse
   resolution (the in-addr.arpa and ip6.arpa namespaces).

In skeletal form, a view-based separation would look something like:

view internal
match-clients xxx # could also use match-destinations, if
listening on multiple IPs
recursion yes # the default
zone "." # with delegations
internal zone #1
internal zone #2
etc.
forwarded zone #1
forwarded zone #2
etc.
view hosting
match-clients all # if not matched above
recursion no
hosted zone #1
hosted zone #2
 etc.

If you separate by named instance and/or server instance, then each of
those views would just become the default view for each instance (with no
"match" clause obviously), and you would protect the "internal" listen-on
address from external queries via your normal access-control methods
(routing, firewalls, etc.)


  - Kevin

P.S. I assume that "corp.intranet.de" in your example config is one of the
domains you described as intended to be resolvable from the Internet, but
you don't show a zone-level "allow-query", so, as it stands, it wouldn't be
resolvable outside of your internal network. I'm guessing this was just an
oversight when you composed your example config...

On Tue, Nov 13, 2018 at 6:01 AM Sig Pam  wrote:

> Hi all!
>
>
>
> I’m really despairing on a configuration, and start to wonder if it is
> possible at all.
>
>
>
> Running Bind 9.5.5, I want to serve IP-Addresses for my internal network
> only, and none from the internet, except for a few domains. The idea is I
> don’t want any intranet client to be able to resolve Internet addresses,
> except for a few domains like Microsoft.com and others.
>
>
>
> My named.config looks like this (shortened, copied together from multiple
> files including others):
>
>
>
> acl intranet_nets {
>
>  192.168.94.0/24;
>
>  192.168.1.0/24;
>
>  192.168.5.0/24;
>
>  };
>
>
>
> options {
>
>  directory "/var/cache/bind";
>
>
>
>  allow-query { localhost; intranet_nets;};
>
>  allow-query-cache { localhost; intranet_nets;};
>
>
>
> recursion no;   # switching this on would resolve ANY Internet address,
> which I don’t want
>
>
>
>  dnssec-validation auto;
>
>
>
>  auth-nxdomain no;# conform to RFC1035
>
>  listen-on-v6 { any; };
>
>
>
> };
>
>
>
> zone "corp.intranet.de" {
>
>  type master;
>
>  file "/etc/bind/db.corp.intranet.de";
>
>  allow-transfer { 192.168.94.242; };
>
>  allow-update { none;};
>
>  };
>
>
>
> zone "94.168.192.in-addr.arpa" {
>
>  type master;
>
>  file "/etc/bind/db.94.168.192";
>
>  allow-transfer { 192.168.94.242; };
>
>  allow-update { none;};
>
>  };
>
>
>
> zone "microsoft.com" IN {
>
> type forward;
>
> forwarders { 9.9.9.9; 194.150.168.168;  8.8.8.8;  8.8.4.4; };
>
> };
>
>
>
>
>
> Running this configuration, my local addresses are correctly resolved,
> external addresses not (good), but DNS-requests for the domain
> Microsoft.com neither (bad!).
>
>
>
> I actually wonder if “forward” is the right keyword (is forward = answer
> to the client: “don’t ask me, ask one of the forwarders” ???), or if I’m
> totally on the wrong way.
>
>
>
> Any support 

Re: Rewrite/Override QTYPE with RPZ

[Kevin Darcy]

The only scenario in which I could see this being accepted by the client,
is if the replacement is a CNAME, since that's a "universal" type. But it's
still unclear what the ultimate intent would be.

   -
Kevin

On Thu, Nov 8, 2018 at 10:45 AM Barry Margolin  wrote:

> In article ,
>  Tom  wrote:
>
> > Hi all
> > Is there a way to override/rewrite QTYPE (ex. MX) with RPZ? If no, is
> > this planned in future releases of BIND?
>
> What would be the point? If a query is for MX, and you return A instead,
> the client won't be able to do anything with it.
>
> --
> 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
>
___
Please visit https://lists.isc.org/mailman/listinfo/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: 2 Questions - forward zone and DNS firewalling

[Kevin Darcy]

My basic rule of thumb is: use forwarding when connectivity constraints
require it. Those constraints may be architectural, e.g. a multi-tiered,
multi-layer network for security purposes, or may be the result of screwups
or unintended consequences, e.g. a routing blackhole. Use forwarding to get
around those blockages.

Now, if one thinks one can use forwarding for efficiency/performance
("forward first") as opposed to using it for connectivity ("forward only"),
then do so based on *documented* , *observed* evidence, not just on
assumptions or conjecture. A lot of folks just take for granted that
forwarding to a rich cache will speed up their lookups. Maybe it will,
maybe it won't -- MEASURE IT.

Also, bear in mind that while forwarding to a rich cache may help your
*best* case, and maybe your *average* case, it may hurt your *worst* case,
since in the case of a cache miss, you have your wasted forwarding attempt
*plus* however long it takes to fetch the data yourself. Your worst case is
going to be the one that causes apps to time out, support calls, tickets,
everyone blaming the DNS infrastructure, etc. You've been warned.


  - Kevin

On Fri, Oct 26, 2018 at 10:41 AM Bob Harold  wrote:

>
> On Thu, Oct 25, 2018 at 4:34 PM N6Ghost  wrote:
>
>> Hi All,
>>
>> have two questions first, I am not a huge fan of using forwarding zones
>> and our "load balancing" team, has there zone delegated to them in a
>> way that needs an internal forward zone to work properly on the inside
>> and not rely on on internet POP.
>>
>> I want to move a core namespace to the load balancer but i want them to
>> let me assign them a new zone thats internally authoritative and use it
>> as the LB domain.
>>
>> which would be:
>> cname name.domain.com -> newname.newzone.domain.com
>>
>> they want:
>> cname name.domain.com -> newname.oldzone.domain.com
>>
>> old zone is directly delagated from outside to them so we need an
>> internal forward zone for it. i dont want to rely on that.
>>
>> any thoughts on this? what can i use to present to management to win
>> this?
>>
>
> The users should never see the domain that the CNAME points at, it is just
> an internal name used by DNS.  If they can change where "
> newname.oldzone.domain.com" points more easily than "
> newname.newzone.domain.com" then they might have a valid reason to want
> it.  Otherwise, newname.newzone.domain.com will be a faster and more
> reliable choice.
>
> Definitely avoid forwarding when possible.  It causes slower lookups and
> more points of failure.  (There will occasional be times when it has some
> advantage, or requirement.)
>
> --
> Bob Harold
>
>
>>
>> next, we where a bind shop but switched to infoblox for some stuff and
>> now out grew it. and are going back to bind.
>>
>> but we started using the dns firewall part of it and they actually
>> really liked it. any ideas for domain blacklisting? via some sort of
>> feed etc? what is everyone doing for that sort of thing?
>>
>> thanks
>>
>> -N6Ghost
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/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: Strange DIG behavior on Windows 10:

[Kevin Darcy]

To be honest, I don't have a lot of experience running dig on Windows, but
I assume it would use the same resolvers as everything else, in which case
they're either statically defined (typically through Control Panel) or
assigned via DHCP.

One thing to consider, though: on Windows, resolvers tend to be assigned
*per-interface*. It's possible that you have some interface that has
assigned resolvers that you can't reach (due to firewall rules, routing
issues, etc.). The resolvers that get chosen may then be dependent on the
binding order of the interfaces, or other factors. For that matter, you
might be trying to use IPv6 resolvers, even though IPv6 may not be routable
from your LAN. Check out ipconfig /all.


  - Kevin

On Tue, Oct 23, 2018 at 6:22 PM Timothy Metzinger 
wrote:

>
>
> I have two windows 10 pro boxes, both with Bind 9.12.3 tools installed.
> On one machine, entering “dig” by itself gives me back the root server list
> as expected.  On the other machine, I get an error that says no name
> servers could be contacted.
>
>
>
> However, if I specify the local name server on that second machine by
> entering dig @192.168.1.250, I get the root server list.
>
>
>
> My logic says that since I can talk to the recursive server, I don’t have
> a firewall issue.  Instead, BIND is not finding the list of name servers
> (by reading the registry)?   I tried putting in a resolv.conf file in
> c:\windows\system32\drivers\etc with contents:
>
>
>
> nameserver 192.168.1.250
>
> nameserver 192.168.1.251
>
> nameserver 8.8.8.8
>
>
>
> And that made no difference.  Running the command prompt as an
> administrator makes no difference.   At this point I’m stumped and welcome
> any suggestions.
>
>
>
> Timothy Metzinger
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/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: need two Domain in Named.local, but not resolv

[Kevin Darcy]

Offhand, it looks like  192.168.201.92  is giving SERVFAIL for anything in
the carag.local zone, but is fine for the olh.local zone. Did the zone load
properly? Look in the logs at startup or reload time.

But, the tools you're using, and how you're using them, makes
troubleshooting very difficult and confusing. First of all, why mix "ping"
troubleshooting with nslookup troubleshooting, if you're sure it's a DNS
problem (i.e. no complications with hosts-file entries, nsswitch.conf or
other such factors)? If it's a DNS issue, stick with DNS
troubleshooting/diagnostic tools

Secondly, without any options, nslookup won't give you an accurate picture
of what's being looked up, behind the scenes. At least use the "-debug"
option to nslookup, or, even better, use a real lookup troubleshooting tool
like "dig".

I'd also suggest targeting *specific* nameservers with your queries, rather
than just querying generically and allowing failover to occur on errors,
which muddies the situation. Single out each nameserver and determine what
it can resolve and what it cannot.

Always use fully-qualified names when troubleshooting, unless the specific
thing you're trying to troubleshoot is suffixing/searchlisting behavior by
the resolver.

As for the failure of the reverse lookup, try it with a 4-octet IP address
instead of 5.

  - Kevin

On Sun, Oct 7, 2018 at 9:12 AM Maurizio Caloro via bind-users <
bind-users@lists.isc.org> wrote:

> Please i need a little help, about DNS Bind Server… i need to replace the
> old one « 115 »
>
> Here i’an on the new one «92 »
>
>
>
> Version
>
> BIND 9.10.3-P4-Debian 
>
>
>
> I try that my DNS server 192.168.201.92 = MasterDNS Server resposible for
> 2 Network Ranges
>
> 1192.168.201.
>
> 2192.168.202.
>
>
>
>
>
> Thanks  for your feedback.
>
> Regards
>
>
>
> --
>
>
>
> root@srvcar012:/etc/bind# ping srvcar002
>
> PING srvcar002.carag.local (192.168.201.118) 56(84) bytes of data.
>
> 64 bytes from srvcar002.201.168.192.in-addr.arpa (192.168.201.118):
> icmp_seq=1 ttl=128 time=0.733 ms
>
>
>
> root@srvcar012:/etc/bind# ping srvcar001.carag.local
>
> ping: srvcar001.carag.local: Name or service not known
>
>
>
>
>
> root@srvcar012:/etc/bind# nslookup srvcar001
>
> ;; Got SERVFAIL reply from 192.168.201.92, trying next server
>
> Server:   192.168.201.115
>
> Address:192.168.201.115#53
>
>
>
> Name:   srvcar001.carag.local
>
> Address: 192.168.201.117
>
>
>
>
>
> root@srvcar012:/etc/bind# nslookup srvcar001
>
> ;; Got SERVFAIL reply from 192.168.201.92, trying next server
>
> Server: 192.168.201.115
>
> Address:192.168.201.115#53
>
>
>
> Name:   srvcar001.carag.local
>
> Address: 192.168.201.117
>
>
>
> root@srvcar012:/etc/bind# nslookup srvcar001.carag.local
>
> ;; Got SERVFAIL reply from 192.168.201.92, trying next server
>
> Server: 192.168.201.115
>
> Address:192.168.201.115#53
>
>
>
> Name:   srvcar001.carag.local
>
> Address: 192.168.201.117
>
>
>
>
>
>
>
>
>
> 
>
>
>
> With the 202 side, this arnt working
>
>
>
> root@srvcar012:/etc/bind# ping srvolh001
>
> ping: srvolh001: Name or service not known
>
>
>
> root@srvcar012:/etc/bind# ping srvolh001.olh.local
>
> ping: srvolh001.olh.local: Name or service not known
>
>
>
> root@srvcar012:/etc/bind# nslookup srvolh001
>
> ;; Got SERVFAIL reply from 192.168.201.92, trying next server
>
> Server: 192.168.201.92
>
> Address:192.168.201.92#53
>
>
>
> ** server can't find srvolh001: NXDOMAIN
>
>
>
> And here this are correct, DNS Server ?
>
>
>
> root@srvcar012:/etc/bind# nslookup srvolh001.olh.local
>
> Server: 192.168.201.92
>
> Address:192.168.201.92#53
>
>
>
> Name:   srvolh001.olh.local
>
> Address: 192.168.202.14
>
>
>
>
>
> root@srvcar012:/etc/bind# nslookup 192.168.168.202.14
>
> Server: 192.168.201.92
>
> Address:192.168.201.92#53
>
>
>
> ** server can't find 192.168.168.202.14: NXDOMAIN
>
>
>
>
>
> root@srvcar012:/etc/bind# cat /etc/resolv.conf
>
> domain carag.local
>
> search carag.local.
>
> nameserver 192.168.201.92
>
> nameserver 192.168.201.115
>
>
>
>
>
> and here my named.conf.local
>
>
>
> root@srvcar012:/etc/bind# cat named.conf.local
>
> //
>
> // Do any local configuration here
>
> //
>
>
>
> // Consider adding the 1918 zones here, if they are not used in your
>
> // organization
>
> //include "/etc/bind/zones.rfc1918";
>
>
>
> zone "carag.local" {
>
> type master;
>
> file "/etc/bind/db.carag.local";
>
> };
>
> zone "201.168.192.in-addr.arpa" {
>
> type master;
>
> file "/etc/bind/db.reverse.carag.local";
>
> };
>
> zone "olh.local" {
>
> type master;
>
> file "/etc/bind/db.olh.local";
>
> };
>
> zone "202.168.192.in-addr.arpa" {
>
> type master;
>
> file "/etc/bind/db.reverse.olh.local";
>
> };
>
>
>
>
> ___
> 

Re: Forward type "only" no longer working (possibly a regression)?

[Kevin Darcy]

One of the most useful initial steps in troubleshooting is to establish
your ability to reproduce the error.

So, I'd look at getting to the command-line of the originating resolver, if
possible, and using a command-line tool like "dig" to generate queries
towards the intended target and see if you get the same SERVFAIL result. In
order to *exactly* replicate the queries, however, you need to understand
what "+E(0)K" in the log means. That's recursive-desired (the default for a
query generated by a command-line tool like "dig"), EDNS0 and a DNSCOOKIE
requested. Supposedly, modern versions of "dig" will set EDNS0 and
DNSCOOKIE by default, so you might be lucky and a straight "dig" with no
special options will replicate the error. If not, you may need to get your
hands on a more modern version of "dig", or use another tool.

Once you've replicated the error, then start changing things. I'd start
with turning EDNS0 and/or DNSCOOKIE on and off. Both of those are
relatively "modern" extensions to DNS (at least, compared to the "classic"
DNS of RFCs 1034 and 1035) and it's possible that the responding server
just doesn't deal with them properly.

With EDNS0, there are different buffer sizes that could, hypothetically, be
tried. But, unless you've tuned that specifically in named.conf, it's
should be the case that the "dig" default is the same as the "named" one,
so it's unlikely that changing buffer size will produce any change in
behavior. It's possible, I suppose...

If you can't get any change of behavior by twiddling those things, then one
would have to delve deeper. But I won't make this post any longer than it
already is :-) That should be enough to get you started...


   - Kevin

On Mon, Oct 1, 2018 at 3:34 PM Karol Babioch  wrote:

> Hi,
>
> Am 01.10.18 um 21:10 schrieb Karol Babioch:
> > Do you have any suggestion / recommendation what I can do to narrow the
> > problem down? I already tried to increase the tracing and enabled query
> > logging, but I couldn't get to the bottom of things. What else can I do
> > here?
>
> as an additional data point, this is what I get with debugging (level 9):
>
> > 01-Oct-2018 21:25:52.976 query-errors: debug 1: client @0x7f89401d4c10
> 10.24.0.1#51206 (mail.babioch.de): view internal: query failed (SERVFAIL)
> for mail.babioch.de/IN/A at query.c:10672
> > 01-Oct-2018 21:25:52.976 query-errors: debug 2: fetch completed at
> resolver.c:9094 for mail.babioch.de/A in 0.030641: SERVFAIL/success
> [domain:babioch.de
> ,referral:2,restart:0,qrysent:0,timeout:0,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0,qminsteps:2]
>
> I really don't get it, the fetch completes just fine according to this
> (SERVFAIL/success). Also the querylog does not indicate what the issue is:
>
> > Okt 01 21:30:53 kvm1.babioch.de named[17380]: client @0x7f15e8056140
> 10.24.0.1#58354 (mail.babioch.de): view internal: query: mail.babioch.de
> IN A +E(0)K (10.24.0.1)
> > Okt 01 21:30:53 kvm1.babioch.de named[17380]: client @0x7f15e8056140
> 10.24.0.1#58354 (mail.babioch.de): view internal: query failed (SERVFAIL)
> for mail.babioch.de/IN/A at query.c:10672
>
> Can one of you BIND gurus see what's wrong here? What else can/should I
> try. I'm pretty much out of ideas for now.
>
> Thank you very much in advance!
>
> Best regards,
> Karol Babioch
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/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: Forward type "only" no longer working (possibly a regression)?

[Kevin Darcy]

You need to get to the root cause of what's causing the SERVFAIL.

Removing "forward only" just masks the problem by telling the resolver
algorithm to fail over to iterative resolution when it encounters the
SERVFAIL. So, sure, the query resolves, but probably not from the correct
server, and probably returns the wrong result. The SERVFAIL is the
proximate cause, and until you solve that, your forwarding to that server
isn't going to work.

Why this behavior changed from BIND 9.10.x to 9.13.x eludes me. It's a clue
to help you get to the root cause of the SERVFAIL, but only a clue. More
diagnosis and testing is required.


- Kevin

On Sat, Sep 29, 2018 at 7:45 PM Karol Babioch  wrote:

> Hi,
>
> after upgrading my bind installation from 9.10.0 to 9.13.3 I'm
> encoutering issues with zones that are forwarded. My setup is somewhat
> complicated, but I was able to simplify it, so hopefully explanations.
>
> Basically I have a split horizon DNS, so on my local resolver I'm
> forwarding specific requests to an internal authoritative nameserver.
>
> The named.conf looks somewhat like this:
>
> > options {
> > listen-on port 53 { 127.0.0.1; 10.24.0.1; };
> > listen-on-v6 port 53 { ::1; };
> > directory "/var/named";
> > pid-file "/run/named/named.pid";
> > recursion yes;
> > allow-query { localhost; 10.24.0.0/16; };
> > };
> >
> > include "/etc/named.rfc1912.zones";
> > include "/etc/named.root.zone";
> >
> > zone "babioch.de" IN {
> > type forward;
> > forward only;
> > forwarders { 10.24.0.10; };
> > };
>
> This used to work fine before the upgrade, but it fails now. When using
> this resolver, I'm running into the following issue:
>
> > dig @127.0.0.1 mail.babioch.de
> >
> > ; <<>> DiG 9.13.3 <<>> @127.0.0.1 mail.babioch.de
> > ; (1 server found)
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28826
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ; COOKIE: bfe2507f6ca6291e360aae925bb00ba55dc000437399d823 (good)
> > ;; QUESTION SECTION:
> > ;mail.babioch.de. IN  A
> >
> > ;; Query time: 1 msec
> > ;; SERVER: 127.0.0.1#53(127.0.0.1)
> > ;; WHEN: So Sep 30 01:32:53 CEST 2018
> > ;; MSG SIZE  rcvd: 72
>
> As you can see the status is "SERVFAIL" and no response is returned. The
> query log for this contains the following information:
>
> > Sep 30 01:33:31 kvm1.babioch.de named[16298]: client @0x7ff0c40ad670
> 127.0.0.1#51022 (mail.babioch.de): query: mail.babioch.de IN A +E(0)K
> (127.0.0.1)
> > Sep 30 01:33:31 kvm1.babioch.de named[16298]: client @0x7ff0c40ad670
> 127.0.0.1#51022 (mail.babioch.de): query failed (SERVFAIL) for
> mail.babioch.de/IN/A at query.c:10672
>
> The line in question is handling stale answers [1]. I'm not entirely
> sure how this applies to my use-case, since nothing should be stale here.
>
> Interestingly enough I can get it working, when I'm removing the
> "forward only" directive from my configuration. This looks like this:
>
> > dig @127.0.0.1 mail.babioch.de
> >
> > ; <<>> DiG 9.13.3 <<>> @127.0.0.1 mail.babioch.de
> > ; (1 server found)
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35694
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ; COOKIE: 85a469a4288546b7b55ea9a65bb00cc92c9846104f77fdab (good)
> > ;; QUESTION SECTION:
> > ;mail.babioch.de. IN  A
> >
> > ;; ANSWER SECTION:
> > mail.babioch.de.  300 IN  A   10.24.0.20
> >
> > ;; Query time: 129 msec
> > ;; SERVER: 127.0.0.1#53(127.0.0.1)
> > ;; WHEN: So Sep 30 01:37:45 CEST 2018
> > ;; MSG SIZE  rcvd: 88
>
> I definitely want the "forward only" directive to make sure that only
> nameservers specified in the "forwarders" directive are contacted - in
> all cases. This seems no longer to be possible. I couldn't find any
> description of this in the change log, so this seems to be a bug and/or
> regression to me.
>
> What do you think? Can anyone verify this? Am I missing or
> mis-understanding something here?
>
> Thank you very much!
>
> Best regards,
> Karol Babioch
>
> [1]:
>
> https://gitlab.isc.org/isc-projects/bind9/blob/v9_13_3/lib/ns/query.c#L10672
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/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: NTP through DNS?

[Kevin Darcy]

I'll just toss in the factoid that NTP can be run on multicast or anycast,
which may negate some of the motivation for using a DNS name to access the
service.


   - Kevin

On Wed, Sep 19, 2018 at 11:38 AM Andrew Latham  wrote:

> On Wed, Sep 19, 2018 at 10:19 AM Ray Bellis  wrote:
>
>> On 19/09/2018 15:59, Mauricio Tavares wrote:
>>
>> >> An NTP serice doesn't belong to a domain, so maybe not (I don't know of
>> >> one off my mind).
>> >>
>> >   Not necessarily; I can name a few universities and business who
>> > offer their own NTP servers to their internal systems. AFAIK, this is
>> > considered good practice.
>>
>> That's not the point that Mukund was making.
>>
>> An NTP server is part of your local network configuration.   Your domain
>> name is also part of your local network configuration.  As such, these
>> two values are often served by DHCP.
>>
>> That does not mean, though, that there is a one-to-one mapping from your
>> domain name to your preferred set of NTP servers.
>>
>> One could have numerous subnets located all over the planet with
>> different NTP servers, but all sharing the same domain name.
>>
>> If it were feasible to store an NTP server address in the DNS it would
>> more logically fit in the in-addr.arpa zone, and not in a forward zone.
>>
>
> Many organizations have per site "views" of the zone so it actually works
> out well. There are many ways of building functional infrastructure. I
> agree there are many applications where this setup would not be useful,
> just addressing OP.
>
>
>>
>> Ray
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>
>
> --
> - Andrew "lathama" Latham -
> ___
> Please visit https://lists.isc.org/mailman/listinfo/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: Net::DNS::Update when Something Goes Wrong

[Kevin Darcy]

On 9/18/2014 12:33 PM, Martin G. McCormick wrote:

This is a perl module but my question is pure bind. Is
anyone familiar enough with this perl module to say whether the
packets are sent as TCP or udp? If udp, one would think that if
a packet was sent to do a job and the DNS failed to receive it
the world would look the same to the sender as it would if the
DNS got the packet and the job went through without a problem.

I have been using this module in some scripts and it
normally works perfectly but on occasion, we have had things
happen such as trying to replace old forward lookups with new
ones using the same IP address but a different A record name.
The old ones hung around along with the new ones to form
redundant A records and nobody was the wiser at the time.
If there is that ambiguity, the fix would be to do
lookups just after the job to verify that everything went as
expected.

and/or use prereqs.

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

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

Re: How to block part of a zone

[Kevin Darcy]

You have multiple choices here.

Loopback is sometimes a bad choice, since the client may try to connect 
to itself, and in pathological cases this could cause an infinite loop.


You could consider an A record with RDATA 0.0.0.0, the null or 
unspecified address. It is not legal for that ever to be a destination 
address for a connection attempt, so it's marginally safer than 127.0.0.1.


For that matter, you don't need to define *any* A (or ) record in 
the zone at all. Then any resolution attempts will get a so-called 
NODATA response (NOERROR, but 0 answers), which the vast majority of 
stub resolvers won't be able to distinguish from NXDOMAIN.


- Kevin

On 9/16/2014 12:20 PM, King, Harold Clyde (Hal) wrote:

I need to block a host in an exterior domain.

Resolve all traffic for example.com from example.com¹s dns servers, but
stop badhost.example.com.
I guess I could become authoritative for badhost.example.com and point the
host to 127.0.0.1.
Does that sound like bad things would happen?

Zone ³badhost.example.com² {
type master;
file ³/etc/named/badhost.example.com.db²;
}

Badhost.example.com. IN SOA localhost (
Admin.localhost
2014091601
3600
900
86
3600 )
NS localhost.
A 127.0.0.1



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

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

Re: A record of domain name must be name server ?

[Kevin Darcy]

On 9/11/2014 3:47 AM, Matus UHLAR - fantomas wrote:

On 10.09.14 18:13, Kevin Darcy wrote:

No, what I'm saying is that if

example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then

where does 48.113.0.203.in-addr.arpa point?


Completely your decision.
Some people will point it at example.com, some will point it at 
www.example.com. What you get is a mish-mosh. No consistency.


Do not mix multiple A and PTR. they are just different things.
You are creating issues where there are none.
The issue is consistency. If you give admins choices where to point a 
PTR, and the RFCs don't provide any clear guidance, you're going to get 
inconsistent results.


If you make www a CNAME to apex, then the RFCs are clear that you 
can't point the PTR to the www name. The *only*legal*choice* is to 
point the PTR at the apex name. You're going to get *much*more* 
consistent results.


Consistency is a good thing, isn't it? Sure, the earth isn't going to 
fall off its axis of rotation just because of the way people point their 
A and PTR records, CNAME or don't CNAME. But if we can nudge people in 
the direction of consistency, and there is no downside, why wouldn't we 
do that? That's what best practices are all about -- impelling people 
towards processes/methods/conventions that ultimately benefit 
*everyone*. Greatest good for the greatest number, and all that.


If, on the other hand, www.example.com is a CNAME to example.com, 
then it's crystal clear where the reverse record will point -- 
example.com. There is no ambiguity or option for inconsistency.


If you point www CNAME @, the 'www' will have both MX and NS records 
same as

example.com.  Which may e.g. cause rejectd on backup MX hosts, apparently
not designed to receive mail for www.example.com.
So, is it better that mail sent erroneously to www.example.com fall 
through the RFC 5321 algorithm and attempt to be delivered to the A 
record? That host is almost certainly is a *web* server and quite likely 
to not even be listening on port 25. After some period of time, the user 
ultimately gets a connection timed out, still retrying NDR and 
scratches their head trying to figure out what went wrong. Meanwhile, 
the sending MTA keeps on retrying, web server sees garbage traffic on 
an off-port and generates ICMP packets back to the source. In the CNAME 
to @ scenario, at least the mail gets rejected promptly by a *mail* 
server, you have a nice clear audit trail on the server side and a 
meaningful error message (e.g. I don't accept mail for the 
www.example.com domain) back to the user.


(Yes, I'm aware that there was a proposal recently discussed on the 
DNSOP list for an MX-target convention to denote no mail service 
offered here. That would presumably solve the problem I cited in the 
previous paragraph. But AFAIK that proposal is many years away from 
widespread adoption, and even if adopted, it puts an extra burden on the 
DNS admins to populate the no service MX record, which, again, is 
going to produce inconsistent results -- some admins will remember to do 
it; many won't).


Obviously, if one wants mail for example.com and www.example.com to be 
delivered to *different* MX targets, then CNAME to @ isn't an option. 
But in the general case, where you don't want mail to www.example.com to 
be deliverable *at*all*, CNAME to @ is quite a viable option; 
arguably, a *better* option, since the failure mode is faster and 
cleaner than directing MTAs to try to deliver mail, as per RFC 5321, to 
a web server.




The same applies for all other RRs for exmaple.com Alan named crap.

Actually, the only other RR type that Alan enumerated specifically was 
NS, which operates on entirely different principles, and serves a 
significantly different function, than MX-based mail routing. Who would 
be looking up www.example.com with QTYPE=NS? Is that even a plausible 
use-case scenario?


What other RR types do you have in mind? SRV records? They have their 
own defined naming structure, which effectively precludes apex naming. 
TXT records used for SPF purposes? Worst case for that is that the same 
hosts trusted to send mail for example.com are also trusted to send mail 
for www.example.com -- but *sending* mail servers are presumably under 
the control (directly or indirectly) of the domain owner, so the 
potential for negative fallout seems rather minimal. Something else? Are 
you thinking that a LOC record should be differentiated between www 
and apex, if the web server is physically in a different datacenter than 
the corporate headquarters of the domain owner?


- Kevin

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

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

Re: A record of domain name must be name server ?

[Kevin Darcy]

Mark,
Depending on implementation, a PTR RRset with multiple 
records either


-- only ever gets answered with the first record of the set (in which 
case the second and subsequent records of the set are just a waste of 
space), or
-- answers in a random, cyclic and/or round-robin fashion (in which 
case, the results are non-deterministic from the standpoint of a client, 
and this can cause problems and/or confusion)


So, although the standards allow multiple RRs, in practical terms, it 
only makes sense for a PTR RRset to contain a *single* RR.


- Kevin

On 9/11/2014 3:45 AM, Mark Elkins wrote:

On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote:

No, what I'm saying is that if

example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then

where does 48.113.0.203.in-addr.arpa point?

Some people will point it at example.com, some will point it at
www.example.com. What you get is a mish-mosh. No consistency.

Although I prefer the use of a CNAME solution (CNAME www.example.com to
example.com), in the case of separate A (and ) records, one could
point the reverse to both names. Nothing wrong with a PTR record having
more than one answer. There is then no inconsistency, just choice. After
all, pretty much every NS record has at least two Right-Hand-Sides
(Answers)



If, on the other hand, www.example.com is a CNAME to example.com, then
it's crystal clear where the reverse record will point -- example.com.
There is no ambiguity or option for inconsistency.

  - Kevin

On 9/10/2014 5:48 PM, Eliezer Croitoru wrote:

Hey Kevin,

This is not an issue at all.
A PTR is different then a A record and can be used by two reverse
domain names and only the owner of the IP addresses space can define
them.
I am not sure if two PTR records for two domains will be applied to
one IP but it is possible for two IP addresses to have the same PTR.

Can we even use a CNAME as a PTR???

Eliezer

On 09/11/2014 12:37 AM, Kevin Darcy wrote:

Also, have you considered the forward/reverse ambiguity that arises when
multiple owner names resolve to the same address? To which of those
names does the PTR point?

  - Kevin

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

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




___
Please visit https://lists.isc.org/mailman/listinfo/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: A record of domain name must be name server ?

[Kevin Darcy]

On 9/11/2014 12:08 PM, Matus UHLAR - fantomas wrote:

On 9/11/2014 3:47 AM, Matus UHLAR - fantomas wrote:

On 10.09.14 18:13, Kevin Darcy wrote:

No, what I'm saying is that if

example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then

where does 48.113.0.203.in-addr.arpa point?


Completely your decision.
Some people will point it at example.com, some will point it at 
www.example.com. What you get is a mish-mosh. No consistency.


Do not mix multiple A and PTR. they are just different things.
You are creating issues where there are none.


On 11.09.14 11:20, Kevin Darcy wrote:
The issue is consistency. If you give admins choices where to point a 
PTR, and the RFCs don't provide any clear guidance, you're going to 
get inconsistent results.


sorry, but again - you are searching for consistency somewhere, where no
consistency (nor a PTR) is required.

Consistency is a good thing, isn't it? Sure, the earth isn't going to 
fall off its axis of rotation just because of the way people point 
their A and PTR records, CNAME or don't CNAME. But if we can nudge 
people in the direction of consistency, and there is no downside, why 
wouldn't we do that? That's what best practices are all about -- 
impelling people towards processes/methods/conventions that 
ultimately benefit *everyone*. Greatest good for the greatest number, 
and all that.


I haven't met a case where this level of consistency would be needed.
Needed? Is that where you're setting the bar here? A little too high, 
I'd say. My point is that consistency is a good thing, and the CNAME to 
@ practice helps to foster that. Whether it's *needed* would be a whole 
other question. Somewhere between necessary and (what Alan called) 
preferences are these things called recommendations or best practices.




I have met a case where the only one A should point to an IP caused
troubles.
Well, sure. Some names, such as zone-apex names, *cannot* own CNAME 
records. If example1.com and example2.com need to resolve to the same 
IP, then, and assuming they are both zone-apex names, you're going to 
have multiple As with the same RDATA, and a reverse-record ambiguity. 
That's unavoidable. All I'm saying, is that in the normal case, where 
you have an option, CNAME to @ makes a lot of sense and should be 
followed.


your argument fails immediately when there's need for more than just A on
www.example.com
If the RDATA needs to be *different* between www and apex, or the 
application/subsystem which accesses the resource makes a distinction 
between canonical names and aliases, sure. I'm not laying down a 
hard-and-fast rule. Of course there will be exceptions, where the 
higher-level protocols or the user requirements demand it.


(Yes, I'm aware that there was a proposal recently discussed on the 
DNSOP list for an MX-target convention to denote no mail service 
offered here. That would presumably solve the problem I cited in the 
previous paragraph. But AFAIK that proposal is many years away from 
widespread adoption, and even if adopted, it puts an extra burden on 
the DNS admins to populate the no service MX record, which, again, 
is going to produce inconsistent results -- some admins will remember 
to do it; many won't).


... and this is just example of it.
An example of what? Of what bad things can happen when (semi-)important 
things are left to mere preference?



The same applies for all other RRs for exmaple.com Alan named crap.

Actually, the only other RR type that Alan enumerated specifically 
was NS, which operates on entirely different principles, and serves a 
significantly different function, than MX-based mail routing. Who 
would be looking up www.example.com with QTYPE=NS? Is that even a 
plausible use-case scenario?


well, me and Alan have shown examples why www CNAME @ is not a good 
idea.
Alan's concern was that the www name could get associated with record 
types that the DNS admin might not have expected. This is not a problem 
for a competent admin, who will have realistic expectations and an 
understanding of CNAME mechanics. You raised the possibility that a mail 
server might reject messages sent erroneously to www and I responded 
that if it's going to fail anyway, at least that failure mode is better 
than a mail server trying to deliver mail to a web server (which is what 
happens in the same scenario when www is an independent A record).


You got anything else?


we both also said it's personal preference.
And I'm saying that's a cop-out. It should be a recommended practice -- 
except where there are special mitigating circumstances which make it 
inappropriate or unworkable -- not merely a preference. Hair styles 
and musical genres are preferences; encouraging consistent 
forward/reverse mappings is something that all DNS admins have a stake 
in, whether they realize it or not.




What other RR types do you have in mind? 


Does it matter at all? It _may_ happen, and it's the case

Re: A record of domain name must be name server ?

[Kevin Darcy]

On 9/11/2014 11:51 AM, Mark Elkins wrote:

On Thu, 2014-09-11 at 11:27 -0400, Kevin Darcy wrote:

Mark,
 Depending on implementation, a PTR RRset with multiple
records either

-- only ever gets answered with the first record of the set (in
which case the second and subsequent records of the set are just a
waste of space), or
-- answers in a random, cyclic and/or round-robin fashion (in which
case, the results are non-deterministic from the standpoint of a
client, and this can cause problems and/or confusion)


Last time I checked, ALL matching records are returned as a single
Resource Record Set - (and in the case of DNSSEC - covered with a single
signature).

What the receiver does with it is up to that receiver... as you say -
some of the information may be discarded.
If the invoker is using the classic gethostbyaddr() interface, then 
it'll only see the RDATA from the first PTR RR, where first is 
determined by the local nameserver implementation and/or the local 
Operating System interface for name resolution.



So, although the standards allow multiple RRs, in practical terms, it
only makes sense for a PTR RRset to contain a *single* RR.

I would still disagree. When there is forward--reverse checking, one
may need the complete answer. I certainly have some processes that do an
exhaustive check.
Certainly if one gets down to the resolver-library level and grovels 
through all of the RRs in the Answer Section of the response packet, one 
could certainly care more than the typical reverse-resolving 
app/subsystem would. And any software that builds up certain heightened 
expectations is likely to complain if those expectations are not met.


- Kevin

On 9/11/2014 3:45 AM, Mark Elkins wrote:


On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote:

No, what I'm saying is that if

example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then

where does 48.113.0.203.in-addr.arpa point?

Some people will point it at example.com, some will point it at
www.example.com. What you get is a mish-mosh. No consistency.

Although I prefer the use of a CNAME solution (CNAME www.example.com to
example.com), in the case of separate A (and ) records, one could
point the reverse to both names. Nothing wrong with a PTR record having
more than one answer. There is then no inconsistency, just choice. After
all, pretty much every NS record has at least two Right-Hand-Sides
(Answers)



If, on the other hand, www.example.com is a CNAME to example.com, then
it's crystal clear where the reverse record will point -- example.com.
There is no ambiguity or option for inconsistency.

  - Kevin

On 9/10/2014 5:48 PM, Eliezer Croitoru wrote:

Hey Kevin,

This is not an issue at all.
A PTR is different then a A record and can be used by two reverse
domain names and only the owner of the IP addresses space can define
them.
I am not sure if two PTR records for two domains will be applied to
one IP but it is possible for two IP addresses to have the same PTR.

Can we even use a CNAME as a PTR???

Eliezer

On 09/11/2014 12:37 AM, Kevin Darcy wrote:

Also, have you considered the forward/reverse ambiguity that arises when
multiple owner names resolve to the same address? To which of those
names does the PTR point?

  - Kevin

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

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




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



___
Please visit https://lists.isc.org/mailman/listinfo/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: A record of domain name must be name server ?

[Kevin Darcy]

On 9/10/2014 11:58 AM, Alan Clegg wrote:

On 9/10/14, 8:42 AM, Sam Wilson wrote:


And you could reduce maintenance very slightly by replacing

www in  A   75.100.245.133

with

www in  CNAME   @

And now you have an MX record, 3 NS records and a bunch of other crap
associated with the WWW address.

And why is that a _bad_ thing?

If I ever change that IP, I want to change it in *one*place*. The CNAME 
allows everything to automatically follow that change. Why necessitate 
multiple updates when a single update will do? If TTL-manipulation is 
necessary in order to minimize caching complications, the number of 
RRset updates is magnified, of course.


MXes and NSes are a non-issue, IMO, since the contexts in which people 
look up a www name (usually end-users trying to access a website) are 
usually quite disjoint from the use cases of MXes (automated systems 
delivering mail) or NSes (nameserver-to-nameserver traffic). I see 
little or no risk of confusion or misdirection.


I suppose it's _possible_ that some day a mail sender might mistype a 
recipient as u...@www.example.com instead of (as they should have) 
u...@example.com, and maybe in that scenario the CNAME will cause the 
recipient address to show up in the headers of the received message in 
an unexpected way. But, to me, this falls under the generic category of 
GIGO (garbage in, garbage out) -- you type something wrong into a 
computer system, you might not get the results you expected...


- Kevin



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

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


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

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

Re: A record of domain name must be name server ?

[Kevin Darcy]

On 9/10/2014 5:20 PM, Alan Clegg wrote:

On 9/10/14, 2:13 PM, Kevin Darcy wrote:

On 9/10/2014 11:58 AM, Alan Clegg wrote:

On 9/10/14, 8:42 AM, Sam Wilson wrote:


And you could reduce maintenance very slightly by replacing

www in  A   75.100.245.133

with

www in  CNAME   @

And now you have an MX record, 3 NS records and a bunch of other crap
associated with the WWW address.

And why is that a _bad_ thing?

(Personal preferences, of course)

Answered before asked.

Well, I was asking about your _particular_ preference, which seemed 
rather clear from your use of the word crap. Why does it matter (in 
_your_ opinion) if the target of the www CNAME owns records of more 
types than just A and/or ?


Also, have you considered the forward/reverse ambiguity that arises when 
multiple owner names resolve to the same address? To which of those 
names does the PTR point?


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

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

Re: A record of domain name must be name server ?

[Kevin Darcy]

No, what I'm saying is that if

example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then

where does 48.113.0.203.in-addr.arpa point?

Some people will point it at example.com, some will point it at 
www.example.com. What you get is a mish-mosh. No consistency.


If, on the other hand, www.example.com is a CNAME to example.com, then 
it's crystal clear where the reverse record will point -- example.com. 
There is no ambiguity or option for inconsistency.


- Kevin

On 9/10/2014 5:48 PM, Eliezer Croitoru wrote:

Hey Kevin,

This is not an issue at all.
A PTR is different then a A record and can be used by two reverse 
domain names and only the owner of the IP addresses space can define 
them.
I am not sure if two PTR records for two domains will be applied to 
one IP but it is possible for two IP addresses to have the same PTR.


Can we even use a CNAME as a PTR???

Eliezer

On 09/11/2014 12:37 AM, Kevin Darcy wrote:

Also, have you considered the forward/reverse ambiguity that arises when
multiple owner names resolve to the same address? To which of those
names does the PTR point?

 - Kevin


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


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





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

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

Re: A record of domain name must be name server ?

[Kevin Darcy]

Based on the zone contents below, you shouldn't have any problem 
changing the 192.168.1.100 address to anything you want.


But, of course, the zone is illegal because it only has 1 NS record 
published at the apex (there is a strict minimum of at least 2), and, as 
it stands now, if it is an Internet-facing zone, it's also illegal due 
to the presence of a private (192.168.*.*) address in the zone. You said 
that 192.168.1.100 is our one of DNS server, but hopefully you don't 
mean that it's a nameserver for *this* zone, or that the zone is not 
Internet-facing, or the 192.168.1.100 address is presented in a NAT 
(network address translated) form to the Internet, since, again, you 
can't use private addresses on the Internet. By definition.


- Kevin
On 9/8/2014 3:43 AM, Pete Fong wrote:

Hi Everybody,

The below item is our DNS (BIND) server configuration. our 
Domain*xxx.com http://xxx.com *is assigned IP address 192.168.1.100 
which is our one of DNS server. Can we change it to our web server IP 
address ? Because we want anybody access our domain *xxx.com 
http://xxx.com* with internet browser then it will go to our 
webpage. Am I correct ? I really appreciate anybody help.


@  IN SOA ns1.xxx.com http://ns1.xxx.com. root.ns1.xxx.com 
http://root.ns1.xxx.com (

  2014090801 ; serial
  2h  ; refresh
  10m; retry
  1w ; expiry
  1h )

IN NS ns1.xxx.com http://ns1.xxx.com.
IN A  192.168.1.100

Thank and Best Regards,
Pete Fong


___
Please visit https://lists.isc.org/mailman/listinfo/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: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'

[Kevin Darcy]

So you care enough about security to implement DNSSEC, but you run your 
forwarder on port 80. Interesting...


- Kevin

On 8/26/2014 8:19 AM, Tomas Hozza wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello.

I found out that when bind is configured as recursive resolver with
dnssec-lookaside set to 'auto' and dlv.isc.org is unreachable, all
lookups for unsigned (UNSECURE) names fail even if the validation
succeeds (IOW the validation of NSEC3 answer proves that DS does not
exist so domain (name) is not signed).


I tested it with one server set up as forwarder running on 127.0.0.1@80
configured not to answer queries for dlv.isc.org (query will timeout).

I have bind (9.9.4-P2) configured with:

forward only;
forwarders { 127.0.0.1 port 80; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;


Doing a lookup for (unsigned) google.com A record times out:
# dig @127.0.0.1 google.com A

;  DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20  @127.0.0.1 google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 12157
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.IN  A

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 26 14:08:03 CEST 2014
;; MSG SIZE  rcvd: 39

in named log I can see:
...
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: in 
authvalidated
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: resuming
nsecvalidate
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking for
relevant NSEC3
26-Aug-2014 13:45:49.126 validating @0x7ff9745af3d0: google.com DS: looking for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates potential closest encloser: 'com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 at
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 proves
name does not exist: 'google.com'
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3
indicates optout
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: NSEC3 at
super-domain com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: looking for
relevant NSEC3
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: in
checkwildcard: *.com
26-Aug-2014 13:45:49.127 validating @0x7ff9745af3d0: google.com DS: nonexistence
proof(s) found
26-Aug-2014 13:45:49.127 fctx 0x7ff97a28a440(google.com/DS): received validation
completion event
26-Aug-2014 13:45:49.127 validator @0x7ff9745af3d0: dns_validator_destroy
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): nonexistence
validation OK
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): clone_results
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): done
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): stopeverything
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): cancelqueries
26-Aug-2014 13:45:49.128 fctx 0x7ff97a28a440(google.com/DS): sendevents
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: in
dsfetched2: ncache nxrrset
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: plain DNSSEC
returns unsecure (google.com): looking for DLV
26-Aug-2014 13:45:49.128 validating @0x7ff974046c80: google.com A: looking for
DLV google.com.dlv.isc.org
...

This looks to me that the result of DNSSEC validation of A record
for google.com proved that it is UNSECURE.

However the validation using DLV proceeds and fails in the end since
dlv.isc.org can not be resolved.


Doing a lookup for (signed) nic.cz A record succeeds:
[root@unused-4-247 ~]# dig @127.0.0.1 nic.cz A

;  DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20  @127.0.0.1 nic.cz A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 25002
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nic.cz.IN  A

;; ANSWER SECTION:
nic.cz. 1163IN  A   217.31.205.50

;; Query time: 7 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 26 14:12:21 CEST 2014
;; MSG SIZE  rcvd: 51


I think this behavior (with unsigned records) may not be completely correct.
I think 

Re: rndc

[Kevin Darcy]

On 7/31/2014 11:56 AM, Reindl Harald wrote:


Am 31.07.2014 um 17:41 schrieb /dev/rob0:

On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote:

i am doing reloads of named with killall -HUP named just because
i disabled rndc completly for security reasons and configurations
are generated with own software only needs named to reload

Hmm, rndc is securable. You don't have to open it to the Internet;
typically you'd just bind it on 127.0.0.1. Then your rndc key will
further secure it against system users.  Your OS can probably give
extra protective layers by firewalling it, such as this Linux
example:

iptables -vA OUTPUT -p tcp --dport 953 -m owner \
\! --gid-owner wheel -j REJECT

(This forces root and other wheel members to chgrp wheel before
they can use rndc, as an extra inconvenience.)

Another option is to use a UNIX domain socket, which, of course
avoids the network altogether.[1]

You're losing a lot of new features without rndc. This is a
throwing out the baby with the bathwater sort of solution. Sure,
this is what you are familiar with and what works for you, but to
disable rndc isn't good advice for readers of this list.  ISC is
moving on

don't get me wrong but if someone creates *any* bind configuration
and zone-files with self developed software there are no features
rndc could provide and so disable something you don't use is the
way to go instead make is secure with other switches
This thread started with I need a way to force named to re-scan for 
interfaces. Since that *is* a feature[] that rndc could provide it 
seems like enabling rndc in a secure way is a good fit for the 
requirement that was raised.


kill -HUP is way more disruptive than necessary for a mere interface 
scan. It's overkill.


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

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

Re: rndc (and now nsupdate too)

[Kevin Darcy]

On 7/31/2014 3:08 PM, /dev/rob0 wrote:

On Thu, Jul 31, 2014 at 05:56:08PM +0200, Reindl Harald wrote:

Am 31.07.2014 um 17:41 schrieb /dev/rob0:

On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote:

i am doing reloads of named with killall -HUP named just
because i disabled rndc completly for security reasons and
configurations are generated with own software only needs
named to reload

Hmm, rndc is securable. You don't have to open it to the

snip

You're losing a lot of new features without rndc. This is a
throwing out the baby with the bathwater sort of solution.
Sure, this is what you are familiar with and what works for
you, but to disable rndc isn't good advice for readers of
this list.  ISC is moving on

don't get me wrong but if someone creates *any* bind
configuration and zone-files with self developed software

... that someone is almost surely doing it wrong.  Zone files?


there are no features rndc could provide and so disable
something you don't use is the way to go instead make is
secure with other switches

The proper tool to manage named configuration and operation, and
which in the best Unix ethic is well suited for automation, is
rndc(8).

The proper tool to manage zone data is nsupdate(8).  Likewise well
suited for automation.

Unfortunately, it seems that no one with an adequate understanding of
BIND has written and released a good management frontend.  Too many
of them are still wallowing around in zone file editing rather than
nsupdate and (as it seems from this thread) sending of signals rather
than rndc.
Written? Yes. Released? Unfortunately not. It's intellectual property of 
my employer.


Even with the nice GUI frontend of Infoblox, we still use our homegrown, 
crudely-formatted web frontend for the vast majority of changes 
(Infoblox being the backend of that frontend), since

a) our existing users are accustomed to it,
b) it's simple enough that even novices can get up to speed on it 
quickly, without the possibility of causing major disruption,
c) the lack of significant eye-candy means it still runs well even in 
slow and/or high-latency locations,
d) it has a more robust ACL system that I haven't seen rivaled in any 
commercial product, and
e) other stuff I've added over the years, like automatic 
external-to-internal sync'ing, and so forth


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

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

Re: One question about 'Stealth servers'

[Kevin Darcy]

I know of no way to do this within BIND itself, but if you Anycast your 
nameservers, and carefully tweak route preferences and whatnot, you 
could ensure that some instances (call it set A) only get used if all of 
the members of another set of instances (call it set B) stop advertising 
the route(s).


Of course, that only works if the box is sufficiently down that it stops 
advertising the route(s). Other failure modes (e.g. zone expired, 
misconfigured, busying out, nameserver process dead) wouldn't 
necessarily trigger failover at the routing level.


If you want finer control, you'd probably have to use a dedicated 
load-balancer-type device.


- Kevin

On 7/23/2014 10:38 PM, 许腾 wrote:

Dear all,
As a beginner of BIND, I'm writing to ask one question about 'Stealth servers'. 
To avoid the access failures arising from the broken down of Authoritative Name 
servers, I'd like to run Stealth servers as back up. My question is how could I 
set the Stealth servers as non-priority so that these Stealth servers could not 
be accessed unless the Authoritative Name servers are broken down? The 
'forward' configuration item could set the servers as priority, is there 
another configuration item could do the contrary thing? Looking forward to your 
reply!

Best wishes,
Teng
___
Please visit https://lists.isc.org/mailman/listinfo/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: Checking proper SPF record

[Kevin Darcy]

http://www.kitterman.com/spf/validate.html

- Kevin

On 7/8/2014 12:43 PM, Alex wrote:

Hi,

I have a mail server that manages mail for about ten domains, using 
bind-9.9.4-12.P2 on fedora20. I'd like to make sure my SPF record in 
my SOA is set up correctly, and hoped someone could help. Currently I 
have the following:


$TTL 1d

@  INSOA ns.example.com http://ns.example.com. 
admin.ns.example.com http://admin.ns.example.com. (

2011041707  ;serial (mmddxx)
3h  ;refresh every 3 hours
1h  ;retry every 1 hr
7d  ;expire in 7 days
1d );minimum ttl 1 day

IN  NS ns.example.com http://ns.example.com.
IN  NS ns1.example.com http://ns1.example.com.
IN  NS ns2.example.com http://ns2.example.com.

A   192.168.1.10

IN  MX  10 smtp.example.com 
http://smtp.example.com.


IN TXT v=spf1 mx a ip4:192.168.1.11/32 
http://192.168.1.11/32 ip4:192.168.2.11/32 http://192.168.2.11/32 
a:smtp.example.com http://smtp.example.com a:smtp1.example.com 
http://smtp1.example.com -all


ns  IN  TXT v=spf1 a -all
ns1 IN  TXT v=spf1 a -all
ns2 IN  TXT v=spf1 a -all
smtpIN  TXT v=spf1 a -all
smtp1   IN  TXT v=spf1 a -all

I believe there is a new SPF TXT entry in addition to the one I've 
created above that's now being used? The references I read were unclear.


Does this look correct? I'd have to add this SOA to every domain the 
mail server manages, correct? The smtp and smtp1 servers are the only 
two servers that should be responsible for this domain.


Any ideas greatly appreciated.
Thanks,
Alex


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

[Kevin Darcy]

You're right: I misinterpreted no name-server as no such host (aka 
NXDOMAIN), but actually your explanation makes more sense.


- Kevin
On 6/9/2014 6:07 PM, Barry Margolin wrote:

In article mailman.401.1402350461.26362.bind-us...@lists.isc.org,
  Kevin Darcy k...@chrysler.com wrote:


That scenario still shouldn't have led to an NXDOMAIN. If none of the
delegated nameservers are responding, you'd get a timeout or SERVFAIL.
So I think there's still some investigation to be done. But using dig
instead of nslookup at least makes things clearer :-)

Where did he say he got NXDOMAIN? He said he got no name-server, which
is not a dig error I've ever seen. Maybe he was abbreviating from No
nameserver could be reached, which is what dig says when it times out
waiting for a reply.



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

[Kevin Darcy]

That scenario still shouldn't have led to an NXDOMAIN. If none of the 
delegated nameservers are responding, you'd get a timeout or SERVFAIL. 
So I think there's still some investigation to be done. But using dig 
instead of nslookup at least makes things clearer :-)


Of course, caching may complicate things here. The NS records published 
at the apex (which I assume were all 6 of them) take precedence over the 
delegation NS'es, so for a period of time, some resolvers would be able 
to resolve names in the zone, and some would not. Eventually, depending 
on your TTLs, everyone would expire the cached NS records and the zone 
would be completely unresolvable.


- Kevin

On 6/9/2014 5:38 PM, Sid Shapiro wrote:
Thanks, Kevin, for your quick reply. In the last few minutes, I've 
come to realize that my problem is likely that the domain is only 
registered with two name servers - the one which were offline. Even 
though the zone has 6 NS records, the .com servers probably only know 
of the ones in the registration. So registration and DNS not in sync. 
Silly mistake.


(And FWIW, I *was* using dig, not nslookup)

--
Sid Shapiro sid_shap...@bio-rad.com mailto:sid_shap...@bio-rad.com
Bio-Rad Corporate IT  - Desk: (510) 741-6846   Mobile: (510) 224-4343


On Mon, Jun 9, 2014 at 2:32 PM, Kevin Darcy k...@chrysler.com 
mailto:k...@chrysler.com wrote:


Well, you shouldn't be getting an NXDOMAIN just because some of
your auth servers are off-line, but you could get some query
timeouts if performance to your failover servers is really bad (or
blocked, due to firewall rules, bad routes, etc.), or, if your
expire times are *really* low, and the master's been down a while,
it's possible the zone may have expired on the slaves.

In any of those cases, I'm suspecting you're using nslookup, and
you might be suffering from its horrible misfeature where it
searchlists on a query failure, and then reports the *last* RCODE
it received as the result of the entire lookup. So, for example,
if your query is www.example.com http://www.example.com and your
searchlist ends in the domain department1.example.com
http://department1.example.com, if the first query fails (e.g.
with a timeout or a SERVFAIL), nslookup might work through the
searchlist, ultimately querying
www.example.com.department1.example.com
http://www.example.com.department1.example.com, which returns
NXDOMAIN, and that's what nslookup (mis-)reports as the result of
the query.

You can avoid this by dot-terminating the original query (thus
inhibiting nslookup's searchlist behavior), or even better, using
a real DNS troubleshooting tool like dig or host. If you want to
continue to use nslookup, at the very least add the -debug flag so
you can see what it's really doing under the covers.

- Kevin

On 6/9/2014 4:36 PM, Sid Shapiro wrote:

Hello,
I've got 6 name-servers, 2 in each of 3 global regions. Each
name-server has a net connection. Each name-server is
authoritative. the domains it server have all six NS records.

My question has to do with redundancy. If one of my regions
goes down, I would have expected that a query against a domain
would reach one of the other region's name-servers. However,
during a maintenance window when one regions was off the air, I
did some simple queries. I did not have a lot of time to do a lot
of detailed testing and tracing. I was simply trying to see if I
could get a query resolved.

What I got, was a no name-server error. I do not have the exact
message, nor the timings. I could see (somehow) that there might
be some time-out issue on the client, but the no name-servers
response came pretty quickly.

This doesn't seem like a configuration problem, although I
suppose it might be. It seems more like a misunderstanding how
redundancy works at the domain level.

Have I totally misunderstood a concept here?
Thanks
--
Sid Shapiro sid_shap...@bio-rad.com mailto:sid_shap...@bio-rad.com
Bio-Rad Corporate IT  - Desk: (510) 741-6846
tel:%28510%29%20741-6846   Mobile: (510) 224-4343
tel:%28510%29%20224-4343


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

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



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

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




___
Please visit https://lists.isc.org/mailman/listinfo/bind-users

Re: slave: WARNING: recursion requested but not available

[Kevin Darcy]

On 6/6/2014 7:35 AM, Reindl Harald wrote:

Am 06.06.2014 13:28, schrieb Matus UHLAR - fantomas:

On 06.06.14 13:13, Reindl Harald wrote:

why does in case of asking the slave always come a
WARNING: recursion requested but not available
even if you dig a A-record he is authoritative?

because you request recursion and the server does not provide it.

use dig +norecurse not to request recursion

i am asking a auth name server for it's own domain
where and why do i request recursion in that case?
dig can't read your mind and thus know what you want to emulate. For 
most queries issued via dig, either a) the user wants to emulate a stub 
resolver, or b) the RD flag doesn't matter either way. That's why RD=1 
is the default. The +norecurse flag -- setting RD=0 -- is one of the 
ways you tell dig to emulate an iterative resolver when it composes its 
query. An even better emulation includes setting a reasonable buffer 
size via EDNS0, since most modern iterative resolvers do that too.


- Kevin

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

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

Re: SPF RR type

[Kevin Darcy]

On 6/5/2014 10:34 AM, Mike Hoskins (michoski) wrote:

-Original Message-
From: Nicholas F Miller nicholas.mil...@colorado.edu
Date: Thursday, June 5, 2014 at 10:25 AM
To: bind-users@lists.isc.org bind-users@lists.isc.org
Subject: SPF RR type


Are SPF RR types finally dead or not? I¹ve read through rfc7208 it
appears that they are:

   SPF records MUST be published as a DNS TXT (type 16) Resource Record
   (RR) [RFC1035] only.  The character content of the record is encoded
   as [US-ASCII].  Use of alternative DNS RR types was supported in
   SPF's experimental phase but has been discontinued.

...but to confuse the issue rfc7208 goes on to say:

   If a future update to SPF were developed that did not
   reuse existing SPF records, it could use the SPF RR type.  SPF's use
   of the TXT RR type for structured data should in no way be taken as
   precedent for future protocol designers.²

Bind-9.10.0-P1 still reports errors if you don¹t have SPF RRs defined
with the SPF TXT records or are not using 'check-spf ignore¹.  Should one
keep existing SPF RRs or remove them? Will future versions of bind stop
reporting errors when SPF RRs don¹t exist?

RFC 7208 is dated April 2014...  Even if/when BIND stops complaining, how
long will it take for the Internet to align with the new standard?  :-)

Look how long BCP38's existed and how many networks don't align despite
obvious benefits to the Internet at large.  I know it's a different ball
of wax...but only kinda.

During such transitional periods, I suggest maintaing the old form for at
least awhile (probably a couple years) to give the world time to update
its configuration.  There used to be quite a few major mail providers who
would bounce or at least flag as spam any mail from hosts not represented
in the domain's SPF TXT record...so the choice of when to change depends
on how much you care (or your users will complain) about misbehaved mail
delivery.


Given the heated and bitter debates over the SPF record type (see 
http://www.ietf.org/mail-archive/web/dnsext/current/maillist.html, 
search SPF, around August of last year), I'm thinking that a couple 
years probably translates into indefinitely or even never.


Some people seem to think the role of the IETF is merely to passively 
document terrible designs and/or implementations...


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

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

Re: stub zones

[Kevin Darcy]

The typical use case for a stub zone is where the delegation chain is 
broken, or incorrect, but you don't want to incur the overhead of 
slaving the zone (or some other sort of bureaucratic snafu like the 
owner/admin of the zone not letting you do zone transfers).


As a general rule, stub zones are usually a lesser evil than forwarding:
A) because there may be no nameservers available for the domain, which 
honor recursion, or
B) in cases where there is a multi-level hierarchy, some of the 
published nameservers for descendant zones may be closer, more reliable, 
etc. than those responsible for the apex of the hierarchy, and the 
algorithm built into named will help to optimize such traffic dynamically


I'm not sure I understand the view complexity you reference. Could you 
clarify? Note that client source address isn't the *only* way to select 
views -- many folks with complicated view configurations use TSIG keys 
as a view-selection mechanism.


- Kevin

On 6/2/2014 5:37 PM, Nex6|Bill wrote:
I guess, i am having issues with this(maybe i am not fully getting 
it), and yea I know large environments sometimes have multiple sets of 
name servers. sometimes department level (i have this issue in my shop 
its a damn mess)


if all the zones are delegated properly the local resolver will query 
its NS, and that NS will know where it should go next, whether its a 
internet side query or navigating the mess of local NS servers that 
some folks have. in the case of DNS views, where the local resolver 
may NOT be able to get to the correct view a forwarder would be better 
so you can point to the internal view NS. This keeps NS servers that 
are authoritative and responsible for handing out resource records
they hand them out. and unless, your dealing with a load balancer 
(which is its own exception) which needs short TTLs, a caching 
forwarder is far better in most cases..


I guess, I am still not sure of the point of a stub zone, where you 
point to a different NS? than the authoritative NS for that zone? 
unless your changing the records

which is all bad



On Monday, June 2, 2014 2:18 PM, John Miller johnm...@brandeis.edu 
wrote:




Not quite, Bill.  You point the zone at a different name server, but
_your_own_nameserver_ still does the iterative queries to make things
happen.  It just queries a different set of nameservers than would
happen through normal delegation.

The only recursive query going on is from the client to your
nameserver.

Since you asked the question, what would you propose as an
alternative
for folks running multiple sets of nameservers with different info
on them?

John


On 06/02/2014 04:52 PM, Nex6|Bill wrote:
 so, stub zones allow you to point a zone to a different name
server, and
 that name-server; to recurse to get the records for that zone.
why? why
 not let DNS work the way it is suppose to and let your name
servers work
 for you to the authoritative name-server to get the records? unless,
 your changing the zone records, which is why most people I know
use it
 for, which is evil :)

 its almost the same, as creating a local zone for something your not
 authoritative for and then having to maintain those records. but, i
 guess their may be cases where it may be useful  i guess


 On Monday, June 2, 2014 1:33 PM, John Miller
johnm...@brandeis.edu mailto:johnm...@brandeis.edu wrote:



Evil?  Seems a bit strong.  Unusual?  Use with caution?  OK.

Stub zones mean that you're using a different set of
authoritative
nameservers for a particular domain.  You're not storing all
of that
domain's records, except through the usual caching process. 
If it's

a domain you control, where's the harm?

Also, let's say that you're nominally a caching-only nameserver.
You're responsible for making iterative queries, and you do
not want
the RD bit set.  AFAIK, stub zones are the way to accomplish
that.
Forward zones just pass recursive queries on to someplace else.

John




On Mon, Jun 2, 2014 at 4:02 PM, Nex6|Bill n6gh...@yahoo.com
mailto:n6gh...@yahoo.com
mailto:n6gh...@yahoo.com mailto:n6gh...@yahoo.com wrote:

recently, a question came up about stub zones came up
and what
they are and are they part of the DNS standards or are they a
good idea. i said, they are evil and should not be used
if you
can avoid it.  they way I understand them is the are when you
create local zones for zones you are NOT authoritative
for. and;
the records in the stub zone do not update when the
authoritative NS does.

correct? thoughts?

  

Re: Reply Code 0x8083 vs 0x8080

[Kevin Darcy]

Why the different RCODES? See RFC 2308. Short version: the NODATA 
response occurs when the QNAME exists, but no records match QTYPE. It 
will also occur if the QNAME is merely a branch to something further 
down in the hierarchy (a so-called empty non-terminal), and owns no 
records of its own.


I'm not sure why NODATA would inhibit search-suffixing, but I just 
confirmed on a Linux platform that it does. Weird.


- Kevin

On 5/29/2014 2:40 PM, Jiann-Ming Su wrote:

What could cause BIND to respond with reply code 0x8083 (no such name) vs 
0x8080 (no error)?

I have an app doing srv queries without the domain name appended.  One time, 
server will respond with no such name (flags 0x8083) which causes the app to 
query again with domain name appended.  Another time, the DNS server responds 
with no error (flags 0x8080) which causes the app to query again without the 
domain suffix appended.

I may very well be debugging an application problem, but I'm curious as to why 
BIND would respond with different codes.  Thanks for any insights.

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

[Kevin Darcy]

If the named instance is responding from authoritative data, it is not 
initiating any outbound transaction, and therefore timeout has no 
meaning in that context.


- Kevin

On 5/19/2014 8:00 PM, Shawn Zhou wrote:


What about non-recursive queries?

In particular case, our test queries are non-recursive and we expect 
the name server should have answers. We are sending test host with 
very high query rate so BIND may be too busy to respond to all the 
queries.


On Monday, May 19, 2014 4:25 PM, Kevin Darcy k...@chrysler.com wrote:



If a client sends a recursive query to the BIND instance, and that
instance needs to fetch the answer from one or more other upstream
sources, then my understanding is that the
resolver-query-timeout global option (see the BIND docs)
controls the timeout for each one of those upstream transactions.
Default value is 10 seconds.

Does that answer your question?

- Kevin

On 5/19/2014 6:15 PM, Shawn Zhou wrote:


I  am looking at some scripts that use IO::Socket::INET and
IO::Select for testing BIND.

UDP sockets are created use use IO::Socket::INET and sockets are
polled via IO::Select at 6-second interval.

 my  $sock = IO::Socket::INET-new(
PeerHost = $server,
PeerPort = $port,
Proto= $protocol,
Blocking = 0,

I'd like to know what the timeout is for the queries.

Thanks,
Shawn


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

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



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

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




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

[Kevin Darcy]

If a client sends a recursive query to the BIND instance, and that 
instance needs to fetch the answer from one or more other upstream 
sources, then my understanding is that the resolver-query-timeout 
global option (see the BIND docs) controls the timeout for each one of 
those upstream transactions. Default value is 10 seconds.


Does that answer your question?

- Kevin

On 5/19/2014 6:15 PM, Shawn Zhou wrote:


I am looking at some scripts that use IO::Socket::INET and IO::Select 
for testing BIND.


UDP sockets are created use use IO::Socket::INET and sockets are 
polled via IO::Select at 6-second interval.


my  $sock = IO::Socket::INET-new(
PeerHost = $server,
PeerPort = $port,
Proto= $protocol,
Blocking = 0,

I'd like to know what the timeout is for the queries.

Thanks,
Shawn


___
Please visit https://lists.isc.org/mailman/listinfo/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: Some GUI for zone updates.

[Kevin Darcy]

On 5/10/2014 3:00 AM, Mimiko wrote:

Hello.

I know there are WEB GUIs for bind, which uses a DB to store its 
information and need read/write access to bind's config files and 
zones files. Is there a GUI utility which will user zone transfers 
with keys and dynamic updates?


In windows I created a simple batch file to update or delete records 
in zones via dynamic update and `nsupdate` utility. But a GUI will be 
much easier to use
I don't know of any open source versions of this, but having written a 
proprietary, company-owned subsystem like that, I'm wondering why you 
think it needs to use zone transfers. Any 
consistency/sanity/referential-integrity checks can be implemented using 
ordinary queries; zone transfers are rather inefficient for the task.


Also, it shouldn't be a hard requirement to wrap around the nsupdate 
utility. If the system is written in Perl, for instance, Dynamic Updates 
(signed or unsigned) can be done via the Net::DNS module. Supposedly 
dnspython (which I haven't used) also supports Dynamic Updates and 
TSIG-authentication.


If you want the subsystem to deal with zone creation/deletion, then you 
either need to allow write access to the config files, or potentially 
you could use the addzone/delzone rndc commands in modern versions of 
BIND (which I have *not* used at all).


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

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

Re: Point domain name of my zone to name in somebody else's zone?

[Kevin Darcy]

On 5/9/2014 6:59 AM, Tony Finch wrote:

Dave Warren da...@hireahit.com wrote:

On 2014-05-08 15:09, Mark Andrews wrote:

But that does not help when you want a MX record at the apex or
some other record at the apex.

I'd argue that it does -- Since the record is now CNAME'd, the MX record is
now under the control of the destination of the CNAME record and MX records
can still be set.

Unfortunately CNAME-pointing-at-MX is an interop disaster area owing to
different MTA's differing opinions about whether it makes sense to rewrite
email addresses in this situation. Avoid.


I actually think that MX records were a boneheaded thing to do, had email
started using SRV records in the first place we might be in a position now
where using SRV records is the defacto standard if not the actual standard for
all services. (No offense to the folks that made MX records happen, I realize
that in historical context it was the correct decision and it solved the very
immediate problem -- I'm just saying that in an ideal world, SRV records
instead of MX records would solved the same problem in a more generic fashion,
and would have pushed us to a better place for other protocols)

It is interesting to look at the old RFCs and see how many false starts it
took to get to the MX design. Mail was the first heavily virtualized
application so I think their failure to generalize was forgivable,
especially since they were also dealing with the massive problem of
gatewaying between dozens of balkanized mail networks.

http://stuff.mit.edu/afs/athena/reference/net-directory/documents/JANET-Mail-Gateways.ps

Indeed. Hindsight is 20/20. Mail was the killer app for the early 
Internet, and providing a way to route it over the Internet, with 
automatic load-balancing and failover, was a major achievement. Sure, 
the IETF could have spent a few more years coming up with a generic 
way to do things, throwing in -- as SRV eventually did -- port 
reassignment, weighting and namespace semantics, but how much would that 
delay have stunted the growth of the nascent technology? Maybe it would 
have resulted in OSI/X.400 surpassing SMTP as the predominant mail 
transport, and we'd all be *miserable*.


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

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

Re: Multi-master (HA)

[Kevin Darcy]

On 5/9/2014 3:01 PM, John Wobus wrote:

...if anyone has specific
thoughts on how to make this sort of thing easier in BIND -- even 
just at

the level of boy, it irritates me that I can't make BIND do X --
such comments will fall on welcoming ears.


I agree that it would be nice if effort were made into making flipping
masters straight-forward, i.e., not require a change to every zone 
declaration

and not force the operator to deal with zone files that suddenly need to
switch between binary and ascii.  (There may be good ways to do this now
that I'm unaware of.)


Where is the line drawn these days between DNS management protocols and 
provisioning protocols? Because, I've long thought the idea of feeding a 
config (i.e. the contents of a named.conf file) to a named instance 
via rndc would be an easy and secure way of quickly reconfiguring it 
to a different role (e.g. from master to slave, or _vice_versa_, for a 
whole bunch of views/zones in one fell swoop). Since the config is in a 
very regular, structured format, I'm sure some sort of encoding and/or 
compression could be employed to make the actual data transfer size 
fairly compact.


The only big gotcha that comes to mind here is if the named.conf is 
segmented via include files with different access privileges (e.g. not 
letting key definitions be world-readable), that segmentation/protection 
would need to be preserved on the receiving side.


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

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

Re: Point domain name of my zone to name in somebody else's zone?

[Kevin Darcy]

On 5/8/2014 5:13 PM, John Levine wrote:

DNSMadeEasy calls this an ANAME record, internally they just lookup
the destination's IP and cache it, updating it as needed.

It works, but it would be nice if this could be done in DNS. Sadly, it
can't, and probably won't in our lifetimes.

I do a similar thing in my DNS crudware, a pseudo-entry in the zone,
every time the background update script runs, it does A and 
lookups and puts the results in the real zone, bumping the SOA serial
if the result changed since last time.  It's a crock, but one that we
all seem to want.

I suppose we could invent something like an ANAME (that's A and
 name), that worked like a restricted CNAME and does an indirect
lookup only for A or  requests.  Or overimplement it with a bitmap
of the RR types to indirect for.

Or, a bitmap of the RR types to *not* indirect for, which
a) often if not usually will be a shorter list (even in the zone apex 
case, you have 2 exclusions -- NS and SOA -- and typically 2 or more of 
A//MX/SPF/TXT as inclusions, potentially even more if the zone is 
DNSSEC-signed), and

b) would automatically cover new RR types as they are defined

As an implementation detail, zone-loading logic could, if desired, 
*automatically* set these bits based on what other record types with the 
same owner name are explicitly defined in the zone file (on the 
reasonable assumption that a data owner wouldn't explicitly define an 
RRset in a zone file, only to have it be hidden forever by an 
indirection record with the same owner name).


Of course, it's one thing to dream up a new RR type, quite another thing 
to get it standardized via the IETF and then change the installed base 
to actually recognize and use it. Also, during the (presumably long) 
transition period, you'd have to use EDNS0 signalling or something 
similar so that a server knows whether a client understands the new 
record type or not. If the client doesn't understand the new type, you 
need a fallback mechanism to cough up usable terminal-node records the 
old-fashioned way.


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

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

Re: Point domain name of my zone to name in somebody else's zone?

[Kevin Darcy]

The apex name of a zone can't own a CNAME, if that's what you're asking. 
E.g. the name example.com can't be a CNAME pointing at 
otherexample.com.


But, of course, you can certainly put A and/or  records at the apex, 
that resolve to one or more addresses in one or more ranges you don't 
own/control.


- Kevin

On 5/6/2014 12:31 PM, Rom, Gloria wrote:


Hello All,

Here's an easy one.

I administer a zone that consists of a few names, each of which points 
to a name in a zone that I do not administer.


Now my project manager wants to resolve the domain name of my zone to 
another name in that foreign zone.


Can I tell him that it can't be done, or have I overlooked a clever 
workaround? I'm running an oldish version of BIND 9.


Thanks,

Glo

Gloria Rom

UCLA Library Digital Initiatives and Information Technology

glor...@library.ucla.edu mailto:glor...@library.ucla.edu

310-206-9784



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

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


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

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

Re: How to setup a backup NameServer?

[Kevin Darcy]

Forwarder selection has been based on RTTs for quite a while now. So, if 
what you're trying to protect against is your primary forwarders being 
DoS'ed, why not just define your primary and backup forwarders in 
the same forwarder list? Due to RTT calculations, the backup 
forwarders would normally not be used (much), if they're slower, but in 
the DoS scenario, the queries would automatically fail over.


If your backup forwarders are *not* significantly slower than your 
primary ones, then *all*the*more*reason* for them to be in the 
forwarder list, in order to provide ongoing DoS protection. (Unless 
they're more expensive to use, perhaps? In that case, you might want 
into some sort of rate-limiting-based and/or load-balancer-based solution).


- Kevin

On 5/3/2014 9:15 PM, houguanghua wrote:

Dave,

sorry for the delay reply.

These zones are not owned by ISP, such as: yahoo.com, facebook.com...
If such backup dns server is ready, ISP will talk to these WEB sites 
to keep synchronization with their authority NSs.

It's maybe a huge project.

Thanks,
Guanghua hou



 Message: 1
 Date: Tue, 29 Apr 2014 22:08:22 -0700
 From: Dave Warren da...@hireahit.com
 To: bind-users@lists.isc.org
 Subject: Re: How to setup a backup NameServer?
 Message-ID: 53608546.4050...@hireahit.com
 Content-Type: text/plain; charset=iso-8859-1; Format=flowed

 On 2014-04-29 18:50, houguanghua wrote:
  A lot of zones will be supported. All popular zones in the ISP.
  Maybe the best solution is to hire some custom programming to develop
  private system.

 How will you obtain copies of all popular zones? Are you just talking
 about zones you host, or things like Google?

 --
 Dave Warren
 http://www.hireahit.com/
 http://ca.linkedin.com/in/davejwarren

 -- next part --
 An HTML attachment was scrubbed...
 URL: 
https://lists.isc.org/pipermail/bind-users/attachments/20140429/a463b663/attachment-0001.html


 --


___
Please visit https://lists.isc.org/mailman/listinfo/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: Forwarding request to another DNS server but the same domain

[Kevin Darcy]

Being authoritative means that you know everything about the zone.

If you know everything about a zone, why ask anyone else?

Split DNS does not follow the DNS paradigm, so there is no standard 
way to implement it, and despite many people asking over the years, 
there is no NXDOMAIN failover forwarding mechanism in BIND, nor is 
there any clear consensus that there *should* be (insert standard 
diatribe against forwarding in general).


Bite the bullet: do parallel updates to both zones, for records that 
need to be present in both versions.


- Kevin

On 4/30/2014 3:55 PM, Jeronimo L. Cabral wrote:
Dear, I would like to ask for solution related with DNS (bind) 
configuration to allow forward requests to another DNS but related 
with the same domain.


I'm asking about two authoritative name servers serving the same 
domain but with different zone file info on each and have one of them 
forward recursive queries to another one if first one cannot find some 
particular subdomain record that is missing in his version of zone file.


My named.conf.local is as follow, but it doesn't work:

zone company.com http://company.com {
type master;
file /etc/bind/zones/company.com.db;
allow-transfer { key company; };
check-names ignore;
forward first;
forwarders { 172.16.1.1; };
};

Thanks a lot,

JeLo



___
Please visit https://lists.isc.org/mailman/listinfo/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: Forwarding request to another DNS server but the same domain

[Kevin Darcy]

Oh, I thought this was an external-versus-internal scenario. But, this 
is even easier.


A) One of the nameservers (pick DNS1 or DNS2) becomes a slave (of the 
stealth variety, if you want) of the other

B) People use nsupdate to maintain the zone

For security, TSIG-sign the updates. For fast change propagation, set up 
NOTIFY if and as necessary.


- Kevin

On 4/30/2014 4:32 PM, Jeronimo L. Cabral wrote:

Dear John, this is my scenario:

1) Office 1: people work with some machines and fill up a local master 
zone company.com http://company.com with records in DNS1
2) Office 2: people works with some others machines and fill up a 
local master zone company.com http://company.com with another 
records in DNS2


So both office have a different master zone.

Both offices belong to the same company, so I need that any client PC 
can resolve a hostname from company.com http://company.com 
domain, independently if this record is in DNS1 or DNS2.


Thanks again, regards.

JeLo



On Wed, Apr 30, 2014 at 5:21 PM, John Miller johnm...@brandeis.edu 
mailto:johnm...@brandeis.edu wrote:


Hi Jeronimo,

First of all, please just tell us the real domain. Yes, we could
try and talk about a fictitious example.com http://example.com
or company.com http://company.com, but having the real domain
name lets us actually query your nameservers.

Let me be sure I understand: you have two DNS servers.  Each of
them is authoritative for the same domain.  Are both set as master?

The two servers have different copies of the zone--what's your
reason for that?

If both servers think they are authoritative for a zone, then they
will answer recursive queries for those zones themselves.  From
the manual:

Forwarding occurs only on those queries for which the server is
not authoritative and does not have the answer in its cache.

What exactly are you trying to achieve?

John



On Wed, Apr 30, 2014 at 3:55 PM, Jeronimo L. Cabral
jelocab...@gmail.com mailto:jelocab...@gmail.com wrote:

Dear, I would like to ask for solution related with DNS (bind)
configuration to allow forward requests to another DNS but
related with the same domain.

I'm asking about two authoritative name servers serving the
same domain but with different zone file info on each and have
one of them forward recursive queries to another one if first
one cannot find some particular subdomain record that is
missing in his version of zone file.

My named.conf.local is as follow, but it doesn't work:

zone company.com http://company.com {
type master;
file /etc/bind/zones/company.com.db;
allow-transfer { key company; };
check-names ignore;
forward first;
forwarders { 172.16.1.1; };
};

Thanks a lot,

JeLo


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

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




-- 
John Miller

Systems Engineer
Brandeis University
johnm...@brandeis.edu mailto:johnm...@brandeis.edu
(781) 736-4619

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

bind-users mailing list
bind-users@lists.isc.org mailto: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: Forwarding request to another DNS server but the same domain

[Kevin Darcy]

I'm still not understanding your constraints. If *all* updates come in 
through Dynamic Update, then you don't need freeze/unfreeze.


- Kevin

On 4/30/2014 6:47 PM, Jeronimo L. Cabral wrote:
In office #1, the company.com http://company.com master zone is 
updated automatically from some Windows machines inn DNS1 and in 
office #2 the same zone is updated manually in DNS2 by the 
administrator who shouldn't update (using freeze and unfreeze) the 
master zone from office #1. This is the scenario, and we need that a 
simple query to DNS1 be responded with any record from both zones.


Thanks again


On Wed, Apr 30, 2014 at 5:54 PM, Kevin Darcy k...@chrysler.com 
mailto:k...@chrysler.com wrote:


Oh, I thought this was an external-versus-internal scenario. But,
this is even easier.

A) One of the nameservers (pick DNS1 or DNS2) becomes a slave (of
the stealth variety, if you want) of the other
B) People use nsupdate to maintain the zone

For security, TSIG-sign the updates. For fast change propagation,
set up NOTIFY if and as necessary.

- Kevin


On 4/30/2014 4:32 PM, Jeronimo L. Cabral wrote:

Dear John, this is my scenario:

1) Office 1: people work with some machines and fill up a local
master zone company.com http://company.com with records in DNS1
2) Office 2: people works with some others machines and fill up a
local master zone company.com http://company.com with another
records in DNS2

So both office have a different master zone.

Both offices belong to the same company, so I need that any
client PC can resolve a hostname from company.com
http://company.com domain, independently if this record is in
DNS1 or DNS2.

Thanks again, regards.

JeLo



On Wed, Apr 30, 2014 at 5:21 PM, John Miller
johnm...@brandeis.edu mailto:johnm...@brandeis.edu wrote:

Hi Jeronimo,

First of all, please just tell us the real domain.  Yes, we
could try and talk about a fictitious example.com
http://example.com or company.com http://company.com,
but having the real domain name lets us actually query your
nameservers.

Let me be sure I understand: you have two DNS servers.  Each
of them is authoritative for the same domain.  Are both set
as master?

The two servers have different copies of the zone--what's
your reason for that?

If both servers think they are authoritative for a zone, then
they will answer recursive queries for those zones
themselves.  From the manual:

Forwarding occurs only on those queries for which the server
is not authoritative and does not have the answer in its cache.

What exactly are you trying to achieve?

John



On Wed, Apr 30, 2014 at 3:55 PM, Jeronimo L. Cabral
jelocab...@gmail.com mailto:jelocab...@gmail.com wrote:

Dear, I would like to ask for solution related with DNS
(bind) configuration to allow forward requests to another
DNS but related with the same domain.

I'm asking about two authoritative name servers serving
the same domain but with different zone file info on each
and have one of them forward recursive queries to another
one if first one cannot find some particular subdomain
record that is missing in his version of zone file.

My named.conf.local is as follow, but it doesn't work:

zone company.com http://company.com {
  type master;
  file /etc/bind/zones/company.com.db;
  allow-transfer { key company; };
  check-names ignore;
  forward first;
  forwarders { 172.16.1.1; };
};

Thanks a lot,

JeLo


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

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




-- 
John Miller

Systems Engineer
Brandeis University
johnm...@brandeis.edu mailto:johnm...@brandeis.edu
(781) 736-4619

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

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




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

bind-users mailing list
bind-users@lists.isc.org  mailto:bind-users

Re: BIND transfers records to Windows DNS server

[Kevin Darcy]

On 4/29/2014 3:12 PM, Roberto Carna wrote:

Dear, I have this scenario:

1) Windows DNS with dynamic update zone (Windows clients)

2) BIND with manually update zone (Linux and Cisco clients)

Is there any way to transfer all BIND zone records to the Windows DNS
in order to have just one and complete zone in the Windows DNS server
???

Not really, but, supposedly, modern versions of BIND understand 
GSS-TSIG, so you could, in theory, have the clients (or their DHCP 
servers) perform their dynamic updates to BIND, and that's what would 
host the one and complete zone, which you could slave/stub as you wish 
to other DNS instances in your environment (e.g. Windows boxes), or have 
them resolve them iteratively if you have enough of a delegation chain 
to support that (e.g. an internal root zone). You'll have to kick the 
manual-editing habit, however, since it's too risky and/or disruptive to 
manually edit a dynamic-update-enabled zone. Use nsupdate instead.


You didn't mention Active Directory, but if that's what you're faced 
with, you could delegate the underscore zones to deal with that (see 
http://www.kuro5hin.org/story/2009/2/1/235152/2142)


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

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

Re: How to setup a backup NameServer?

[Kevin Darcy]

I'm not sure this makes sense from an architectural standpoint. If all 
of the authoritative NSes are down, where is this backup nameserver 
getting its data from, and how current is that data?


If slightly *stale* data is acceptable, in the absence of all 
authoritative NSes, then why not just set up your regular 
nameserver(s) as stealth slaves of the zone(s)? Why dedicate a special 
backup nameserver for this function? What value does that add?


- Kevin
On 4/27/2014 11:30 PM, houguanghua wrote:

Dear all,

Does bind support backup nameserver? This nameserver isn't 
regeristered and not accessed in normal situation. Only when all 
authority NSs is down, this backup nameserver will be accessed by 
Local DNS server.
 How to configure this backup NS and how to configure in the local DNS 
server?


Thanks,
Guanghua Hou


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

[Kevin Darcy]

Are you running *other*, non-network-service functions on these boxes 
besides BIND/MM? If not, then you might find an appliance-based 
solution like Bluecat or Infoblox might be more cost-effective than 
adding a DNS-management layer to a generic server. Your security folks 
should love you too, since appliances are hardened (usually they don't 
even have a OS-like command line or a superuser function). Lastly, if 
you're planning to implement things like Anycast, HA clustering, IPv6, 
etc. these things are probably a lot easier for an appliance that 
already has these capabilities built in, than hacking the OS to support 
them. DNSSEC is likely to be a lot easier too.


The argument for appliances becomes even stronger if you want to support 
other network services, e.g. DHCP, NTP, discovery.


If, on the other hand, you're running other stuff on those servers, 
besides network services, or you just *have* to have that OS-level 
control down to the kernel, filesystems, devices, etc. it might make 
sense to stick with an agent- or wrapper-based solution like you already 
have (MM). I think IPControl (by British Telecom) is also a strong 
player in that space.


- Kevin

On 4/28/2014 12:31 PM, Baird, Josh wrote:

Hi,

We currently use the Men  Mice DNS/IPAM/DHCP suite which is essentially a front-end 
wrapper for BIND.  We deploy our own BIND boxes and simply install the Men  Mice 
agent on them which allows us to centrally manage the zones from a GUI (or CLI) based interface.

I'm curious about the other enterprise solutions that are on the market.  Bluecat 
is the first one that comes to mind, but I'm completely unfamiliar with their product.  Does 
their product run alongside native BIND (like MM) or do I need to purchase their own 
appliances and place them all over my network?

Are there any other suggestions for products similar to Men  Mice and Bluecat 
that I should be looking at?  I'm looking for DNS and IPAM and central management.

Thanks,

Josh

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

[Kevin Darcy]

I misspoke a bit about DNSSEC. That's not an OS-level thing (unless you 
want to hook in an HSM or something like that), so there's no reason to 
think that an appliance-based solution would be better at it than an 
agent/wrapper-based solution.


- Kevin

On 4/28/2014 12:57 PM, Baird, Josh wrote:

Kevin,

No - our DNS servers do only one thing depending on their role - either to 
serve internal clients (caching/recursive/override external authoritative) or 
to serve authoritative external clients.  I used to cringe at these appliance 
based solutions because I want to be in control of BIND and the server's 
operating system - but, they are beginning to sound more attractive since they 
don't require someone with operating system knowledge run maintain the 
application.  The bonuses would be things like DNSSEC an Anycast support out of 
the box.

Thanks,

Josh

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kevin Darcy
Sent: Monday, April 28, 2014 12:50 PM
To: bind-users@lists.isc.org
Subject: Re: Enterprise IPAM/DNS Solutions

Are you running *other*, non-network-service functions on these boxes besides BIND/MM? If not, 
then you might find an appliance-based solution like Bluecat or Infoblox might be more cost-effective 
than adding a DNS-management layer to a generic server. Your security folks should love you too, since 
appliances are hardened (usually they don't even have a OS-like command line or a 
superuser function). Lastly, if you're planning to implement things like Anycast, HA 
clustering, IPv6, etc. these things are probably a lot easier for an appliance that already has these 
capabilities built in, than hacking the OS to support them. DNSSEC is likely to be a lot easier too.

The argument for appliances becomes even stronger if you want to support other 
network services, e.g. DHCP, NTP, discovery.

If, on the other hand, you're running other stuff on those servers, besides 
network services, or you just *have* to have that OS-level control down to the kernel, 
filesystems, devices, etc. it might make sense to stick with an agent- or wrapper-based 
solution like you already have (MM). I think IPControl (by British Telecom) is also a 
strong player in that space.

  - Kevin

On 4/28/2014 12:31 PM, Baird, Josh wrote:

Hi,

We currently use the Men  Mice DNS/IPAM/DHCP suite which is essentially a front-end 
wrapper for BIND.  We deploy our own BIND boxes and simply install the Men  Mice 
agent on them which allows us to centrally manage the zones from a GUI (or CLI) based interface.

I'm curious about the other enterprise solutions that are on the market.  Bluecat 
is the first one that comes to mind, but I'm completely unfamiliar with their product.  Does 
their product run alongside native BIND (like MM) or do I need to purchase their own 
appliances and place them all over my network?

Are there any other suggestions for products similar to Men  Mice and Bluecat 
that I should be looking at?  I'm looking for DNS and IPAM and central management.

Thanks,

Josh

___
Please visit https://lists.isc.org/mailman/listinfo/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: Zone transfer doesn't work when I set allow-update statement

[Kevin Darcy]

allow-update + manual editing of zone file = bad.

Use nsupdate.
- Kevin

On 4/25/2014 4:03 PM, Jeronimo L. Cabral wrote:
Dear, I'm using Bind 9.8.4 with a master / slave scenario. Zone 
transfer works OK when I have this config in named.conf.local from 
master server, add some A records and execute service bind9 reload:


zone company.com.ar http://company.com.ar {
type master;
file /etc/bind/zones/company.com.ar.db;
allow-transfer { key company; };
check-names ignore;

After that I add the allo-update statement and restart bind9 service:

zone company.com.ar http://company.com.ar {
type master;
file /etc/bind/zones/company.com.ar.db;
allow-transfer { key company; };
allow-update { 172.12.88.3; 10.8.91.7;};
check-names ignore;

Finally, I add some A records in my company.com.ar 
http://company.com.ar zone and increment the serial number, then I 
execute service bind9 reload but the Slave doesn't receive the new 
records. The only way Slave receives the new records is when I execute 
service bind9 restart in Master which is not the idea.


What is the problem please ???

Thanks a lot,

JeLo








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

[Kevin Darcy]

On 4/14/2014 2:58 PM, Steven Carr wrote:

On 14 April 2014 18:53, Felix Rubio Dalmau felixrubiodal...@gmail.com wrote:

 it is not actually a pure caching server (at least I didn't wanted it 
to be :S). I have server at home, and the DNS is properly configured at the 
internet. The problem is that my router is not capable to redirect my requests 
to my server when they come from the LAN. So, I have had to configure a 
dhcp+dns server to give the IPs to the machines in the LAN, and to use the dns 
server to resolve the local server using db.server.local and db.192 files.

db.server.local wasn't in your config and your query is for
www.server.org, myserver.org was listed in your config file.


 I understand that forward only; will not hurt but, right? After 
setting it, I do the dig and I get:

Setting it to forward only means that anything that the server is not
authoritative for it will forward to the specified servers.
Actually -- small correction -- it's the forwarders statement that 
triggers _that_ behavior. Forward only/forward first is just a 
refinement of what happens if the forwarders are unresponsive (as 
implied in the remainder of your paragraph).


Some additional semantic nitpicking...


If you do
not have that set then there are occasions where your DNS server will
go to the Internet root and start to search for the requested record
recursively,

I think you mean iteratively here.

if you're fine with that then is there a reason why you
are forwarding requests to other DNS servers?

I think you mean iterating rather than forwarding here.

End semantic nitpicking :-)

why not just allow your
local DNS server to handle the whole resolution process?


Totally agreed. Forwarding should not be added to a named.conf unless it 
is well considered and justified. Will not hurt? It very well *might* 
hurt. It often *does* hurt.


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

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

Re: Help with DKIM record

[Kevin Darcy]

What isn't clear so far is whether the TXT record you're looking up is 
in the myserver.org zone or some other zone.


If you're authoritative for myserver.org, you're authoritative for *all* 
of myserver.org. named isn't going to do failover forwarding just 
because you neglected to add a TXT record to your zone file. It'll give 
a negative response to the query. forward first/forward only has no 
effect whatsoever on that behavior.


- Kevin
On 4/14/2014 12:02 PM, Felix Rubio Dalmau wrote:

Maybe this is my problem: I have not created any zone file :s. The only files 
I've created/modified are:

### named.conf.local
include /etc/bind/rndc.key;
zone myserver.org {
 type master;
 file /etc/bind/db.myserver.local;
 allow-update { key rndc-key; };
};
zone 1.168.192.in-addr.arpa {
 type master;
 file /etc/bind/db.192;
 allow-update { key rndc-key; };
};
### named.conf.options
options {
 directory /var/cache/bind;
 forwarders {
91.126.224.5;
91.126.224.6;
 };

allow-query {
192.168.1.0/24;
127.0.0.1;
};

allow-transfer {
192.168.1.0/24;
127.0.0.1;
};

 dnssec-validation auto;
 auth-nxdomain no;# conform to RFC1035
 listen-on-v6 { any; };
empty-zones-enable no;
};
###

I thought that when requesting fields that are not available in the local dns 
server, such requests would be forwarded to the forwarders and its answers 
cached :S. What should I do?

Felix

On Monday 14 April 2014 16:35:10 Steven Carr wrote:

On 14 April 2014 15:59, Felix Rubio Dalmau felixrubiodal...@gmail.com wrote:

What files, exactly? Named.conf.local and named.conf.options is enough?

Yep, and the zone files that you have created that contain the TXT
records you want to query for.

Steve


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

[Kevin Darcy]

Regardless of what you've been told, the resolvers (nameservers) in 
/etc/resolv.conf are tried *in*sequence*, and if a valid response (where 
NXDOMAIN _is_ a valid response) is received from one resolver, none of 
the others are tried. So, I'm surprised that your 
mix-and-match-resolvers hack actually works. The only thing that comes 
to mind is that the Windows DNS is so horked that it's returning 
SERVFAIL for names outside of its authoritative domains. That would 
trigger failover to another resolver, but that's an *ugly* way to 
integrate BIND and Windows DNS.


Instead of guessing at such things, learn how to use tcpdump/Wireshark 
and find out what's really happening under the covers. I haven't seen a 
resolver implementation send queries *simultaneously* to all resolvers, 
since circa Windows 95. And I've never seen it on Linux.


As for a long-term solution, either define an internal root zone (with 
conditional forwarding exceptions for the external stuff you *need* to 
resolve), or, if you must, forward by default to the Internet and then 
define all of the private stuff as master/slave/stub on your internal 
servers.


- Kevin
On 4/8/2014 6:08 AM, Bryan Harris wrote:

Hello all,

We have a sort of private DNS such that servers can lookup zones that don’t 
actually exist in the real, public DNS, they just exist within our private 
NOCs.  In addition, we have always had both Windows AD handling the Windows 
side of things and we have had BIND handling Linux.

When the BIND servers don’t know about a domain, they forward to a public 
server such as google’s 8.8.8.8 thing.  For some reason the Windows guys aren’t 
allowed that option on their DNS (I believe it’s a security requirement), so 
any Windows server that DOES need public DNS resolution always has a BIND 
server listed in the TCP/IP properties of the network interface (from what I 
have seen, it’s usually not the first DNS server in the list).

Anyway, up until now Windows servers primarily got DNS answers via AD (except 
as mentioned above), and Linux servers via the BIND servers.  Recently, 
however, we have enabled AD authentication on Linux, meaning the Linux servers 
need to know about the AD domains (well, they need to know about the kerberos 
and ldap service records and whatnot).

The current mechanism is to put the Windows AD server into the resolv.conf 
BEFORE the BIND servers, since, as has been explained to me a Linux server will 
perform a query against all three simultaneously (that doesn’t immediately ring 
true to me, it’s just what I was told).  While this does seem to work, I’ve 
been wondering if it would be of any benefit to instead let the BIND servers 
know about the AD zones in some way, allowing us to continue with our “Linux 
sends all queries to BIND” methodology.

As I understand BIND could be theoretically doing conditional forwarding, or it 
could use stub zones, or perhaps could be a slave with AD as the master.  Is it 
just as well to leave things alone?  Or would one of these be preferable to its 
current setup?  Any advice or guidance would be greatly appreciated.

Thanks in advance.

V/r,
Bryan
___
Please visit https://lists.isc.org/mailman/listinfo/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: Delegation of part of a zone to a global server load balancer

[Kevin Darcy]

I'm assuming you have forwarding set up. Make sure to set forwarders { 
}; in the aelabad.net zone definition. Failure to do so means that your 
recursive queries for names in subzones forward out towards the 
Internet, instead of following the delegations down to the 
austin-energy.net nameservers, as you intended.


I concur with Mike Hoskins that delegating a *single* zone for each set 
of load-balancers, and then aliasing the names to targets underneath 
that delegation point, is a more scalable and manageable way to handle 
GSLB (as opposed to delegating each individual name to be load-balanced).


E.g.

;; ANSWER SECTION:
international.chrysler.com. 7200 IN CNAME int.us3.lb.chrysler.com.
int.us3.lb.chrysler.com. 10 IN  A   129.9.96.29
int.us3.lb.chrysler.com. 10 IN  A   129.9.64.29

;; ANSWER SECTION:
us3.lb.chrysler.com.28800   IN  NS gssoddi1.extra.chrysler.com.
us3.lb.chrysler.com.28800   IN  NS gsssdci1.extra.chrysler.com.

- Kevin

On 4/7/2014 10:16 AM, McDonald, Dan wrote:
What's the right way to delegate individual zone records to a global 
server load balancer, which is just a simple DNS server that checks 
to see if a server is up and if so adds the address to the rotation 
for resolution.


I've tried simple delegation using ns records, but I don't get 
resolution.  In this example, nsg3 and 4 are my global server load 
balancers for the outlook.aelabad.net zone,  and ns3.aelabad.net is 
the start of authority for  the aelabad.net zone.



Daniel-McDonalds-iMac:~ mcdonalddj$ dig outlook.aelabad.net +norecurse 
@ns3.aelabad.net



;  DiG 9.8.3-P1  outlook.aelabad.net +norecurse @ns3.aelabad.net

;; global options: +cmd

;; Got answer:

;; -HEADER- opcode: QUERY, status: NOERROR, id: 25051

;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1


;; QUESTION SECTION:

;outlook.aelabad.net.INA


;; AUTHORITY SECTION:

outlook.aelabad.net.1200INNSnsg4.austin-energy.net.

outlook.aelabad.net.1200INNSnsg3.austin-energy.net.


;; ADDITIONAL SECTION:

nsg3.austin-energy.net.918INA10.10.9.3


;; Query time: 1 msec

;; SERVER: 10.1.9.34#53(10.1.9.34)

;; WHEN: Mon Apr  7 09:05:42 2014

;; MSG SIZE  rcvd: 105

Daniel-McDonalds-iMac:~ mcdonalddj$ dig outlook.aelabad.net 
@nsg3.austin-energy.net



;  DiG 9.8.3-P1  outlook.aelabad.net @nsg3.austin-energy.net

;; global options: +cmd

;; Got answer:

;; -HEADER- opcode: QUERY, status: NOERROR, id: 8783

;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0


;; QUESTION SECTION:

;outlook.aelabad.net.INA


;; ANSWER SECTION:

outlook.aelabad.net.10INA10.10.223.52


;; Query time: 3 msec

;; SERVER: 10.10.9.3#53(10.10.9.3)

;; WHEN: Mon Apr  7 09:03:03 2014

;; MSG SIZE  rcvd: 72

Daniel-McDonalds-iMac:~ mcdonalddj$ dig outlook.aelabad.net 
@ns3.aelabad.net



;  DiG 9.8.3-P1  outlook.aelabad.net @ns3.aelabad.net

;; global options: +cmd

;; Got answer:

;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 14770

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0


;; QUESTION SECTION:

;outlook.aelabad.net.INA


;; AUTHORITY SECTION:

net.686INSOAa.gtld-servers.net. nstld.verisign-grs.com. 1396879162 
1800 900 604800 86400



;; Query time: 2 msec

;; SERVER: 10.1.9.34#53(10.1.9.34)

;; WHEN: Mon Apr  7 09:03:17 2014

;; MSG SIZE  rcvd: 110






___
Please visit https://lists.isc.org/mailman/listinfo/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: CNAME to an external domain

[Kevin Darcy]

On 3/25/2014 9:01 AM, Ian Braun wrote:

Hello,

We have a bind server (v9.6) that's hosts mydomain.com 
http://mydomain.com.  I'm trying to create a CNAME for 
host.mydomain.com http://host.mydomain.com to point to 
host.otherdomain.com http://host.otherdomain.com.  I don't host 
otherdomain.com http://otherdomain.com.


My entry currently reads:
sipIN   CNAME sip.otherdomain.com http://sip.otherdomain.com.

But my DNS server isn't resolving it.  It just returns a list of root 
nameservers.
Are you *just* getting a list of root nameservers (i.e. a totally 
*empty* Answer Section)? What RCODE is being returned? Or, are you 
perhaps getting the CNAME in the Answer Section? If you're getting the 
CNAME, then that's all another nameserver needs in order to resolve the 
name.


Or, were you expecting that your authoritative nameserver would be 
performing recursion for clients?




I've searched this mailing list and found threads that said this 
should work.  But also saw a post that said this isn't allowed 
(http://www.experts-exchange.com/Networking/Linux_Networking/Q_27656615.html)


I couldn't see the incorrect answer, to mock it, since it's behind a 
paywall.


- Kevin

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

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

Re: localhoast A record?

[Kevin Darcy]

On 3/21/2014 9:03 AM, Casey Deccio wrote:
On Fri, Mar 21, 2014 at 8:50 AM, Mitchell Kuch mi...@basejp.com 
mailto:mi...@basejp.com wrote:


Hello -

I've adopted a number of zones and most of them contain localhost in
a 127.0.0.1 records. I'm curious what current RFC standards state and
what the community considers best practice. RFC1537 states that zones
should contain a localhost record, but it seems that practice was
obsoleted by RFC1912. Is anyone aware of negative consequences with
leaving such records in place, perhaps a XSS vulnerability?

I'm itching to remove the records but thought I'd check to see if
there was a legacy use case.


I would take a look at the query logs for the zones in question.  You 
might be surprised at how many queries are being made by systems that 
are applying a suffix from the search list because of the lack of of 
an entry for localhost in the hosts file or the mishandling thereof.


I wouldn't be surprised by any quantity or variety of harebrained 
queries that clients make, but that doesn't mean I'm going to add 
entries for all that garbage in an attempt to make those clients 
happier. As far as I'm concerned, localhost falls into the same 
it's being looked up but shouldn't be category, and I do not add it as 
a matter of course.


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

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

Re: Audit the consistency of zone files on DNS servers

[Kevin Darcy]

On 3/15/2014 6:09 AM, Maren S. Leizaola wrote:

On 3/15/2014 1:53 AM, Kevin Darcy wrote:

On 3/14/2014 8:28 AM, Maren S. Leizaola wrote:

Hello,
 What do you guys recommend to audit every resource
record in a zone file against all the records in all the DNS servers
that host the zone file.

I want  something that I feed the master zone file and then goes to 
each

NS server and ensures that each of the records are identical in all of
them.

What I want to be able to detect are serial number errors, where a zone
has been updated but the serial number has not changed. In this
circumstances comparing SOA of all the servers would not report any
errors, but the zone file in the different servers are incorrect.


Well, you're only *medium* paranoid, at most. If you were *really* 
paranoid, you'd crypto-sign your transfers.


Crypto signed no signed, AXFR what ever etc, if the DNS servers are 
malfunctioning and sending the wrong replies to queries I would like 
to be able to audit that..


Or use Dynamic Update exclusively for DNS record maintenance, so that 
forgetting to update the serial number after a change is a thing of 
the past[1].


- Kevin

[1] For the nit-pickers out there, the statement is true _even_for_ 
SOA record changes, since they don't take unless you increment 
the serial number (as per serial-number arithmetic) as part of the 
change.





So Dynamic updates, to a master? then IXFR, accross different type of 
DNS servers lots of room for malfunction...


Can someone provide an answer that does not refer to zone transfers?


Whatever tool you use to audit is going to have lots of room for 
malfunction as well.


I think you're just doubting for the sake of doubting for the sake of 
doubting. Which makes me regret the time I've already invested in this 
foolishness...


- Kevin

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

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

Re: Audit the consistency of zone files on DNS servers

[Kevin Darcy]

On 3/14/2014 8:28 AM, Maren S. Leizaola wrote:

Hello,
 What do you guys recommend to audit every resource
record in a zone file against all the records in all the DNS servers
that host the zone file.

I want  something that I feed the master zone file and then goes to each
NS server and ensures that each of the records are identical in all of
them.

What I want to be able to detect are serial number errors, where a zone
has been updated but the serial number has not changed. In this
circumstances comparing SOA of all the servers would not report any
errors, but the zone file in the different servers are incorrect.
Or use Dynamic Update exclusively for DNS record maintenance, so that 
forgetting to update the serial number after a change is a thing of 
the past[1].


- Kevin

[1] For the nit-pickers out there, the statement is true _even_for_ SOA 
record changes, since they don't take unless you increment the 
serial number (as per serial-number arithmetic) as part of the change.


___
Please visit https://lists.isc.org/mailman/listinfo/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: Audit the consistency of zone files on DNS servers

[Kevin Darcy]

On 3/14/2014 2:39 PM, Maren S. Leizaola wrote:

On 3/14/2014 9:20 PM, Stephane Bortzmeyer wrote:

On Fri, Mar 14, 2014 at 12:33:47PM +,
  Phil Mayers p.may...@imperial.ac.uk wrote
  a message of 25 lines which said:


dig @server zone axfr file
diff file file.real

If you're really paranoid, it may not be sufficient since a server may
reply differently to normal DNS queries and to zone file transfer
requests (for instance if the server is also authoritative for a
child zone, see RFC 5936, section 3.2).




Thank you both for your replies.

I am paranoid and I don't think zone transfers are a good method.
 I want something that looks at the file, intelligently looks at each 
record and sends the right types of queries to all the DNS servers.


We are never sure how bug free bind is. As I am using other DNS 
servers I am not sure how reliably they interactive with Bind...
So trust I nothing until it has been provent to work time and time 
again


I am surprised that there isn't a standard tool out there to do this, 
it seems pretty obvious to me.


Well, you're only *medium* paranoid, at most. If you were *really* 
paranoid, you'd crypto-sign your transfers.


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

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

Re: How to create a fake root server?

[Kevin Darcy]

Either set up a *root* zone, with a delegation to your TLD, and those 
other nameservers will be configured with hints files


or

You'll have to use some other mechanism -- e.g. slave, stub -- on those 
nameservers, so that they know how to resolve names in your TLD.


- Kevin

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


The TLD server settings:

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

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

dnssec-validation auto;

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

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

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

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

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

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


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


What am I doing wrong here?

Sincerely, Peter


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

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

Hi Kevin,

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

I have created a closed Internet on 172.16.x.x where I would like to
put up a root server for .loc, where several other ISP-DNS servers, 
with
domains, are referred to. I've managed to create those ISP-DNS 
servers

which works fine. But I'm having trouble to create the root DNS server
with Bind. I haven't found any useful examples at the web yet.

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

. 3600 SOA server.example.net. hostmaster.example.net. 1 3600 1200 
2419200 3600

. 3600 NS server.example.net.
. 3600 NS another.example.net.
server.example.net. 3600 A 1.2.3.4
another.example.net. 3600 A 1.2.3.5


It's for a school project.

Regards, Peter


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

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

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

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

 - Kevin


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

Hi guys,

I'm doing a virtual internet

Re: How to create a fake root server?

[Kevin Darcy]

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


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


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


- Kevin


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

Hi guys,

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


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

Running BIND 9 at every server.

Any suggestions or good links are highly appreciated.

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


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





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

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

Re: Internal clients' queries for myhostname. get sent to forwarders. Why?

[Kevin Darcy]

Options:

1) Change nameservice-switch order (e.g. /etc/nsswitch.conf) on your 
hosts to prefer another source of name resolution (e.g. /etc/hosts) 
which can resolve the shortname. Thus DNS is never used for these lookups
2) Simply :-) change your DNS architecture fundamentally, from one which 
forwards requests to the Internet by default (aka the Microsoft way), 
to one with an internal root zone and conditionally forwarding only 
those parts of the namespace that your internal clients actually need to 
see.


- Kevin

On 3/10/2014 3:58 PM, Andreas Ntaflos wrote:

Hi list,

I hope I succeeded in articulating the problem we are facing and I
apologize for the length of this post.

Short version:

Using Bind 9 on Ubuntu 12.04 for internal DNS (master for zones
dc01.example.at., 7.1.10.in-addr.arpa., ...) with forwarders (ISP's
nameservers) for everything outside of internal zones.

The Problem: Clients, when running hostname -f or hostname -i,
create queries for myhostname. which are sent to the forwarders which
respond with NXDomain. This generates load on the forwarders and exposes
our internally used hostnames, both of which seems unnecessary and
possible dangerous.

This doesn't seem like normal or healthy behaviour. What can we do to
stop it?

Long version:

In our internal networks we are running Bind 9 on Ubuntu 12.04
(9.8.1.dfsg.P1-4ubuntu0.8). The nameserver is configured to be master
for the zone dc01.example.at (obviously we don't use example, but
the other domain components are real). It also serves in-addr.arpa zones
for the internal IP addresses (7.1.10.in-addr.arpa., and so on).
Recursion is enabled for internal clients.

The internal nameserver uses our ISP's nameservers as forwarders for
everything outside of the zones for which it is master.

All clients in our internal networks have names like
auth01.mgmt.dc01.example.at or puppet02.dev.dc01.example.at. All
clients' resolvers are configured with one nameserver and multiple
search domains, like this:

# /etc/hosts:
127.0.0.1 localhost

# /etc/resolv.conf:
nameserver 10.1.7.42
search mgmt.dc01.example.at dc01.example.at

Clients are Ubuntu and Debian machines (10.04, 12.04, Lenny, Wheezy).

This all works fine (and has for years now), but recently we became
aware of the fact that whenever a client system runs hostname -f or
hostname -i it will ask the internal nameserver for hostname plus each
search domain (which is fine), AND for the plain hostname with a
trailing dot (which is not fine). I can see this from the nameserver's
query logs and from tcpdump.

For example, on auth01.mgmt.dc01.example.at the nameserver gets asked for:

auth01.mgmt.dc01.example.at.
auth01.dc.example.at.
auth01.

The nameserver replies correctly with the client's FQDN or IP address
for the first query, as well as with NXDomain for the second query (also
correct) but then forwards the third query (auth01.) to the configured
forwarders (our ISPs nameservers). This naturally returns NXDomain.

I am confused and worried by this behaviour. Since we have quite a few
hosts in our internal networks (all running Puppet agents) the
forwarders get hit with requests for hostname. like above multiple
times per second. It also exposes to the forwarders the hostnames of our
internal machines, which isn't great.

Is this the expected behaviour? What can we do to stop our internal
nameserver from forwarding queries for hostname. to our ISPs nameservers?

I have not included any Bind configuration or zone files here, but I can
provide anything needed to facilitate debugging this issue. Please let
me know!

Thanks in advance for any help and pointers, particularly RTFM. I have
had a really hard time googling this :(

Andreas



___
Please visit https://lists.isc.org/mailman/listinfo/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: Internal clients' queries for myhostname. get sent to forwarders. Why?

[Kevin Darcy]

On 3/10/2014 6:05 PM, Andreas Ntaflos wrote:

On 2014-03-10 22:23, Kevin Darcy wrote:

Options:


First, thanks a lot for the reply! So it seems what I described is 
indeed the expected behaviour for the type of DNS we operate?



1) Change nameservice-switch order (e.g. /etc/nsswitch.conf) on your
hosts to prefer another source of name resolution (e.g. /etc/hosts)
which can resolve the shortname. Thus DNS is never used for these 
lookups


This might be a solution but I find that our DNS setup is just complex 
enough that relying on /etc/hosts would probably introduce more 
problems. Then there's managing /etc/hosts on hundreds of machines, 
which we could of course do with Puppet, but I find that highly 
unappealing. Currently we use Puppet to ensure /etc/hosts contains 
just 127.0.0.1 localhost and nothing else.
That's pretty hardcore. I think it's more common for /etc/hosts to 
resolve the shortname and at least the primary FQDN of the local host.





2) Simply :-) change your DNS architecture fundamentally, from one which
forwards requests to the Internet by default (aka the Microsoft way),
to one with an internal root zone and conditionally forwarding only
those parts of the namespace that your internal clients actually need to
see.


I confess that I didn't think there was any feasible way other than 
what you call the Microsoft way to operate this kind of internal 
DNS. I also don't think I've ever consciously heard of the setup you 
describe. Can you point me to some reading material on what this 
entails and how to get there?
Well, there's 2 pieces to this: the authoritative core for the root 
zone, and then the conditional forwarding for the external namespaces 
that need to be made visible.


For setting up and running an internal root on a single primary master 
server, just look at the Internet Standards and/or BIND documentation, 
since an internal root zone isn't fundamentally different than the 
root zone, or for that matter, much different from any regular zone that 
you define (the major difference being, there is no parent from which to 
delegate it). Once you have the internal root up on its primary master, 
then you should define some slaves (as per the documentation), at least 
some of which should be *published* slaves (as per standards, you need 2 
or more of those). Outside of your authoritative core, you may then 
define other internal nameservers with a hints file containing all of 
your internal published slaves for the root zone. Essentially, you're 
re-creating, on a small scale, what is done on the Internet -- an 
authoritative core for root, with edge nameservers pointing to that 
core with their hints files.


For conditional forwarding, again, look at the BIND documentation 
(pseudo-zones of type forward). These need to be defined on *every* 
nameserver where you want the external namespaces to be visible (a 
configuration-management system helps here, to ensure configuration 
consistency; you mentioned you were using Puppet). For a forwarded 
*external* zone, you want forward only as the mode, since otherwise 
your internal boxes will try to use your internal root (which will give 
the wrong information) for names in the zone, whenever the forwarders 
are unavailable. Another big gotcha with BIND: if you want to 
conditionally forward a namespace, and you're authoritative for its 
closest-enclosing ancestor zone (potentially that ancestor zone is your 
internal root if there's nothing defined in between), you need to 
*delegate* the zone that you want to conditionally forward. It doesn't 
really matter what you delegate it *to* -- it can be something bogus -- 
but the delegation needs to *exist* in order for BIND to see the zone 
cut and forward appropriately.


Last but not least, if you conditionally forward a namespace (e.g. 
example.com) outside, and then you want to carve out an _exception_ to 
that namespace internally (e.g. internal.example.com), that has, itself, 
one or more subzone levels to its hierarchy (e.g. 
foo.bar.internal.example.com), then, on any nameserver that isn't 
authoritative for *all* of those subzones in the hierarchy, you should 
use the BIND-idiomatic forwarders { }; syntax to cancel forwarding 
for the exception namespace, e.g.


zone example.com {
type forward;
forward only;
forwarders { 192.0.2.1; 203.0.113.1; };
};

zone internal.example.com {
type slave; // or master, or stub...
file internal.example.com;
forwarders { }; // cancel forwarding for all subzones
};

Failure to do so will cause queries in subzones (e.g. 
foo.bar.internal.example.com) to forward according to the 
closest-enclosing *forwarded* zone (example.com in the above example), 
which will attempt to resolve externally, rather than internally.


(Obligatory: I would have preferred to see this implemented more 
intuitively as a forward cancel, forward not or forward 
not-for-subzones mode choice among forward only and forward first. 
Forwarding

Re: how to hidden the salve

[Kevin Darcy]

If you have zone-transfer permission, make a stealth slave. That, plus a 
static-stub definition on your local server, and you're set.


Or, to simplify things even further, make the local server the stealth 
slave (this makes some assumptions about your connectivity to the 
authoritative nameservers for the zone).


- Kevin

On 2/25/2014 9:49 AM, houguanghua wrote:

Sorry.  My description isn't very clear.

The local dns server isn't a stealth slave. I need a stealth slave and 
the local dns server can query it when all public NSs are out of service.


Thanks!
Guanghua


 Date: Mon, 24 Feb 2014 13:41:03 -0500
 From: Kevin Darcy k...@chrysler.com
 To: bind-users@lists.isc.org
 Subject: Re: how to hidden the salve
 Message-ID: 530b923f.8070...@chrysler.com
 Content-Type: text/plain; charset=iso-8859-1; Format=flowed

 I guess I'm still not understanding your requirements. In my thinking,
 the local DNS server would *be* a stealth slave. Why are you 
considering

 these as 2 separate instances?

 - Kevin

 On 2/24/2014 9:56 AM, houguanghua wrote:
  Dan,
 
  Yes, also-notify can hide the slave name server. But local dns server
  can't know where is 'stealth' slave too.
 
  Thanks,
  Guanghua
 
  
  Date: Fri, 21 Feb 2014 07:50:05 -0600
  From: Daniel McDonald dan.mcdon...@austinenergy.com
  To: Untitled bind-users@lists.isc.org
  Subject: Re: bind-users Digest, Vol 1769, Issue 1
  Message-ID: cf2cb5ad.6ae8e%dan.mcdon...@austinenergy.com
  Content-Type: text/plain; charset=US-ASCII
 
  On 2/21/14 3:39 AM, houguanghua houguang...@hotmail.com wrote:
 
   kevin,
  
   How does the local name server learn where is the 'stealth' slave?
  For the
   'stealth' slave isn't in the NS records.
 
  Also-notify directive. Either in an options stanza or a zone stanza.
 
  
   thanks,
   Guanghua
 
  --
  Daniel J McDonald, CISSP # 78281
 
 
 
   Date: Thu, 20 Feb 2014 10:48:36 -0500
   From: Kevin Darcy k...@chrysler.com
   To: bind-users@lists.isc.org
   Subject: Re: how to hidden the salve
   Message-ID: 530623d4.3000...@chrysler.com
   Content-Type: text/plain; charset=iso-8859-1; Format=flowed
  
   A stealth slave has a full copy of the zone, is not published 
in the

   NS records, and can resolve names in the latest copy of the zone
  that it
   transferred, even if all of the published NSes are down due to a 
DDoS

   attack.
  
   So, does that not meet the requirements?
  
   - Kevin
  
   On 2/20/2014 1:28 AM, houguanghua wrote:
Stealth slave doesn't fully meet the requirement. It's just 
part of

the requirement to not publish the slave name server in the NS
records. Further more, the 'stealth' slave is quired by local DNS
server only when all name servers in the NS records are out of
  service
( maybe in case of ddos attack).
Guanghua
--
On 2/19/2014 11:54 AM, Kevin wrote:
Date: Wed, 19 Feb 2014 11:54:44 -0500
From: Kevin Darcy k...@chrysler.com
To: bind-users@lists.isc.org
Subject: Re: how to modify the cache
Message-ID: 5304e1d4.5000...@chrysler.com
mailto:5304e1d4.5000...@chrysler.com
   
Not a good solution. Even under normal circumstances, there 
will be

temporary bottlenecks, dropped packets, etc.. that will trigger
  failover
and users will get different answers at different times. Not 
good for

support, maintainability, user experience/satisfaction, etc.
   
If all you want is resilience, and you own/control the domain in
question, why not just slave it (stealth slave, i.e. you don't
  need to
publish it in the NS records)?
   
If you *don't* own/control the domain in question, what business
  do you
have standing up a fake version of it in your own
  infrastructure? Not
a best practice.
   
- Kevin
   
On 2/19/2014 4:51 AM, houguanghua wrote:
 Steven,

 Your solution is very good. It can forward the queries to
 the specified name servers first.

 But if the specified name server is enabled only when normal 
dns

  query
 process is down. How to configure the local DNS server? The 
detailed

 scenario is descibed in below figure:


   
--
| Root |
| nameServer |
/ -
(2)/
/
-- --- -
| Client | __(1)\ | Local | ___(3)_\ |
Authority |
| Resolver | / | DNS Server | X / | DNS
Server |
--  -
\
\(4)
\
\ 
| Hidden |
| DNS Server |

   
 Normally,
 1) A internet user wants to access www.abc.com 
http://www.abc.com

http://www.abc.com/,
 a DNS request is sent to local DNS server
 2) Local DNS server queries the root name server, the .com name
 server to get the Authority Name Server of abc.com
 3) local DNS server queries the Authority name server, and gets

Re: how to hidden the salve

[Kevin Darcy]

I guess I'm still not understanding your requirements. In my thinking, 
the local DNS server would *be* a stealth slave. Why are you considering 
these as 2 separate instances?


- Kevin

On 2/24/2014 9:56 AM, houguanghua wrote:

Dan,

Yes, also-notify can hide the slave name server.  But local dns server 
can't know where is 'stealth' slave too.


Thanks,
Guanghua


Date: Fri, 21 Feb 2014 07:50:05 -0600
From: Daniel McDonald dan.mcdon...@austinenergy.com
To: Untitled bind-users@lists.isc.org
Subject: Re: bind-users Digest, Vol 1769, Issue 1
Message-ID: cf2cb5ad.6ae8e%dan.mcdon...@austinenergy.com
Content-Type: text/plain; charset=US-ASCII

On 2/21/14 3:39 AM, houguanghua houguang...@hotmail.com wrote:

 kevin,

 How does the local name server learn where is the 'stealth' slave? 
For the

 'stealth' slave isn't in the NS records.

Also-notify directive. Either in an options stanza or a zone stanza.


 thanks,
 Guanghua

--
Daniel J McDonald, CISSP # 78281



 Date: Thu, 20 Feb 2014 10:48:36 -0500
 From: Kevin Darcy k...@chrysler.com
 To: bind-users@lists.isc.org
 Subject: Re: how to hidden the salve
 Message-ID: 530623d4.3000...@chrysler.com
 Content-Type: text/plain; charset=iso-8859-1; Format=flowed

 A stealth slave has a full copy of the zone, is not published in the
 NS records, and can resolve names in the latest copy of the zone 
that it

 transferred, even if all of the published NSes are down due to a DDoS
 attack.

 So, does that not meet the requirements?

 - Kevin

 On 2/20/2014 1:28 AM, houguanghua wrote:
  Stealth slave doesn't fully meet the requirement. It's just part of
  the requirement to not publish the slave name server in the NS
  records. Further more, the 'stealth' slave is quired by local DNS
  server only when all name servers in the NS records are out of 
service

  ( maybe in case of ddos attack).
  Guanghua
  --
  On 2/19/2014 11:54 AM, Kevin wrote:
  Date: Wed, 19 Feb 2014 11:54:44 -0500
  From: Kevin Darcy k...@chrysler.com
  To: bind-users@lists.isc.org
  Subject: Re: how to modify the cache
  Message-ID: 5304e1d4.5000...@chrysler.com
  mailto:5304e1d4.5000...@chrysler.com
 
  Not a good solution. Even under normal circumstances, there will be
  temporary bottlenecks, dropped packets, etc.. that will trigger 
failover

  and users will get different answers at different times. Not good for
  support, maintainability, user experience/satisfaction, etc.
 
  If all you want is resilience, and you own/control the domain in
  question, why not just slave it (stealth slave, i.e. you don't 
need to

  publish it in the NS records)?
 
  If you *don't* own/control the domain in question, what business 
do you
  have standing up a fake version of it in your own 
infrastructure? Not

  a best practice.
 
  - Kevin
 
  On 2/19/2014 4:51 AM, houguanghua wrote:
   Steven,
  
   Your solution is very good. It can forward the queries to
   the specified name servers first.
  
   But if the specified name server is enabled only when normal dns 
query

   process is down. How to configure the local DNS server? The detailed
   scenario is descibed in below figure:
  
  
 
  --
  | Root |
  | nameServer |
  / -
  (2)/
  /
  -- --- -
  | Client | __(1)\ | Local | ___(3)_\ |
  Authority |
  | Resolver | / | DNS Server | X / | DNS
  Server |
  --  -
  \
  \(4)
  \
  \ 
  | Hidden |
  | DNS Server |
  
 
   Normally,
   1) A internet user wants to access www.abc.com http://www.abc.com
  http://www.abc.com/,
   a DNS request is sent to local DNS server
   2) Local DNS server queries the root name server, the .com name
   server to get the Authority Name Server of abc.com
   3) local DNS server queries the Authority name server, and gets 
the IP

  
   But when the Authority name server is down, the internet user won't
   get the IP address. My solution is as follows:
   a) A hidden name server with low performance is deployed. When
   authority name server can't be accessed, local dns server will 
access

   the hidden server.
   b)The hidden server is never used in normal situation. It act as
   a cold backup for authority name server.
   c) The zone file in the hidden server is the same as that
   configuration in the authority name server
   d) The hidden name server doesn't appear in the NS records
   of authority name server
  
   Btw, all above doesn't consider the cache in the local dns server.
  
  
   Best Regards,
   Guanghua
  
  
Date: Mon, 17 Feb 2014 09:09:13 +
Subject: Re: how to modify the cache
From: sjc...@gmail.com
To: houguang...@hotmail.com
CC: bind-users@lists.isc.org
   
On 17 February 2014 01:17, houguanghua houguang...@hotmail.com
  wrote:
 I want to override the IP address of NS, for I want to use other

Re: how to hidden the salve

[Kevin Darcy]

A stealth slave has a full copy of the zone, is not published in the 
NS records, and can resolve names in the latest copy of the zone that it 
transferred, even if all of the published NSes are down due to a DDoS 
attack.


So, does that not meet the requirements?

- Kevin

On 2/20/2014 1:28 AM, houguanghua wrote:
Stealth slave doesn't fully meet the requirement.  It's just part of 
the requirement  to not publish the slave name server in the NS 
records. Further more, the 'stealth' slave is quired by local DNS 
server only when all name servers in the NS records are out of service 
( maybe in case of ddos attack).

Guanghua
--
On 2/19/2014 11:54  AM,  Kevin wrote:
Date: Wed, 19 Feb 2014 11:54:44 -0500
From: Kevin Darcy k...@chrysler.com
To: bind-users@lists.isc.org
Subject: Re: how to modify the cache
Message-ID: 5304e1d4.5000...@chrysler.com 
mailto:5304e1d4.5000...@chrysler.com


Not a good solution. Even under normal circumstances, there will be
temporary bottlenecks, dropped packets, etc.. that will trigger failover
and users will get different answers at different times. Not good for
support, maintainability, user experience/satisfaction, etc.

If all you want is resilience, and you own/control the domain in
question, why not just slave it (stealth slave, i.e. you don't need to
publish it in the NS records)?

If you *don't* own/control the domain in question, what business do you
have standing up a fake version of it in your own infrastructure? Not
a best practice.

- Kevin

On 2/19/2014 4:51 AM, houguanghua wrote:
 Steven,

 Your solution is very good. It can forward the queries to
 the specified name servers first.

 But if the specified name server is enabled only when normal dns query
 process is down. How to configure the local DNS server? The detailed
 scenario is descibed in below figure:



  --
 | Root|
| nameServer |
  / -
   (2)/
 /
--  ---   -
  | Client | __(1)\ | Local   | ___(3)_\ | 
Authority|
  | Resolver | / | DNS Server | X   / | DNS 
Server |

   --    -
 \
\(4)
 \
 \   
| Hidden   |
| DNS Server |


 Normally,
 1) A internet user wants to access www.abc.com http://www.abc.com 
http://www.abc.com/,

 a DNS request is sent to local DNS server
 2) Local DNS server queries the root name server, the .com name
 server to get the Authority Name Server of abc.com
 3) local DNS server queries the Authority name server, and gets the IP

 But when the Authority name server is down, the internet user won't
 get the IP address. My solution is as follows:
 a) A hidden name server with low performance is deployed. When
 authority name server can't be accessed, local dns server will access
 the hidden server.
 b)The hidden server is never used in normal situation. It act as
 a cold backup for authority name server.
 c) The zone file in the hidden server is the same as that
 configuration in the authority name server
 d) The hidden name server doesn't appear in the NS records
 of authority name server

 Btw, all above doesn't consider the cache in the local dns server.


 Best Regards,
 Guanghua


  Date: Mon, 17 Feb 2014 09:09:13 +
  Subject: Re: how to modify the cache
  From: sjc...@gmail.com
  To: houguang...@hotmail.com
  CC: bind-users@lists.isc.org
 
  On 17 February 2014 01:17, houguanghua houguang...@hotmail.com 
wrote:

   I want to override the IP address of NS, for I want to use other
 authority
   DNS which isn't registered.
 
  For that you use forwarding. Create a zone statement for the zone in
  question and forward the queries to a different name server. You don't
  need to mess with the cache.
 
  https://mknowles.com.au/wordpress/2009/07/20/bind-forwarding-zone/



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

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


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

[Kevin Darcy]

Not a good solution. Even under normal circumstances, there will be 
temporary bottlenecks, dropped packets, etc.. that will trigger failover 
and users will get different answers at different times. Not good for 
support, maintainability, user experience/satisfaction, etc.


If all you want is resilience, and you own/control the domain in 
question, why not just slave it (stealth slave, i.e. you don't need to 
publish it in the NS records)?


If you *don't* own/control the domain in question, what business do you 
have standing up a fake version of it in your own infrastructure? Not 
a best practice.


- Kevin
On 2/19/2014 4:51 AM, houguanghua wrote:

Steven,

Your solution is very good. It can forward the queries to 
the specified name servers first.


But if the specified name server is enabled only when normal dns query 
process is down. How to configure the local DNS server? The detailed 
scenario is descibed in below figure:



--
   |Root |
   | nameServer |
 /  -
 (2)/
   /
 --    -
| Client | __(1)\ |   Local | ___(3)_\ | 
Authority|
| Resolver | / | DNS Server |   X   / | DNS 
Server  |

 -- -
   \
\(4)
 \
  \  
|  Hidden  |
| DNS Server |
 
Normally,
  1) A internet user wants to access www.abc.com http://www.abc.com, 
a DNS request is sent to local DNS server
  2) Local DNS server queries the root name server, the .com name 
server to get the Authority Name Server of abc.com

 3) local DNS server queries the Authority name server, and gets the IP

But when the Authority name server is down, the internet user won't 
get  the IP address.  My solution is as follows:
 a) A hidden name server with low performance is deployed. When 
authority name server can't be accessed, local dns server will access 
the hidden server.
 b)The hidden server is never used in normal situation. It act as 
a cold backup for authority name server.
 c) The zone file in the hidden server is the same as that 
configuration in the authority name server
 d) The hidden name server doesn't appear in the NS records 
of  authority name server


Btw, all above doesn't consider the cache in the local dns server.


 Best Regards,
Guanghua


 Date: Mon, 17 Feb 2014 09:09:13 +
 Subject: Re: how to modify the cache
 From: sjc...@gmail.com
 To: houguang...@hotmail.com
 CC: bind-users@lists.isc.org

 On 17 February 2014 01:17, houguanghua houguang...@hotmail.com wrote:
  I want to override the IP address of NS, for I want to use other 
authority

  DNS which isn't registered.

 For that you use forwarding. Create a zone statement for the zone in
 question and forward the queries to a different name server. You don't
 need to mess with the cache.

 https://mknowles.com.au/wordpress/2009/07/20/bind-forwarding-zone/


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

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


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

[Kevin Darcy]

Bad performance, bad reliability, clandestine IP-over-DNS tunnels 
between networks that are supposed to be isolated...


Is that enough?

Understanding the pros and cons of iterative versus recursive resolution 
is one of the few things still separating us from the MCSE savages...


- Kevin

On 2/17/2014 5:44 PM, Doug Barton wrote:

On 02/17/2014 11:37 AM, Kevin Darcy wrote:

Ugh, that mixes apples (recursive resolution) and oranges (iterative
resolution).


Out of curiosity, what bad thing do you think will happen if you mix 
these two functions?


Doug

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


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





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

[Kevin Darcy]

To clarify, it's sometimes necessary to mix iterative and recursive 
resolution in the same nameserver instance, maybe even the same view. 
Oftentimes, there simply is no choice, because the source of the zone 
information doesn't make an authoritative nameserver available, only a 
forwarder (thus the insidious, viral effect of forwarding; forcing not 
only your own infrastructure into recursive resolution, but that of 
everyone who wants to talk to you as well, ultimately culminating in a 
spiderweb of point-to-point dependencies).


What I meant by mixing (possibly not the best word choice) is choosing 
a recursive option if an iterative option is available, all other things 
being equal. Perhaps it would have been better for me to merely promote 
stub or static-stub as an iterative alternative to forwarding, than 
to complain about mixing.


- Kevin
On 2/17/2014 5:56 PM, Kevin Darcy wrote:
Bad performance, bad reliability, clandestine IP-over-DNS tunnels 
between networks that are supposed to be isolated...


Is that enough?

Understanding the pros and cons of iterative versus recursive 
resolution is one of the few things still separating us from the MCSE 
savages...


- Kevin

On 2/17/2014 5:44 PM, Doug Barton wrote:

On 02/17/2014 11:37 AM, Kevin Darcy wrote:

Ugh, that mixes apples (recursive resolution) and oranges (iterative
resolution).


Out of curiosity, what bad thing do you think will happen if you mix 
these two functions?


Doug

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


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





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


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





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

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

Re: how to modify the cache

[Kevin Darcy]

Indeed. Regular stub only overrides the parent's delegation NS 
records; static-stub overrides the apex NS records of the zone as 
well. My uses of the words stub (which I intended to cover both forms 
of stubbing) and published (which I intended to cover both the 
delegating and apex records) were both ambiguous. Sorry for the confusion.


- Kevin

On 2/17/2014 6:08 PM, Cathy Almond wrote:

Use a stub zone if you want to override published NSes _without_
crossing the very-important boundary between iterative and recursive
resolution.

Actually no - use static-stub (newer versions of BIND) - otherwise the
NS records received from the zone may override the NS that you want to use.
___
Please visit https://lists.isc.org/mailman/listinfo/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