RE: Authoritative dns with private IP for hostname

[Darcy Kevin (FCA)]

RFC 1918 forbade the publishing of private addresses outside of the enterprise:

"Indirect references to [private] addresses should be contained within the
enterprise. Prominent examples of such references are DNS Resource
Records and other information referring to internal private
addresses. In particular, Internet service providers should take
measures to prevent such leakage."

Having said that, however, BIND doesn't prevent you publishing such addresses 
to the Internet, since it doesn't really know -- *cannot* know, in advance -- 
whether the data is going to be queried from the Internet or not.

I'm not aware of ISPs that filter customer DNS traffic for RFC 1918 addresses 
either.

As Greg pointed out, the addresses aren't going to be routable anyway, but even 
in the absence of routability, there are Information Security concerns: if 
someone -- let's call them a business partner -- trusts your DNS *domain*, and 
you publish private addresses associated with names in that domain, then a 
malicious actor could potentially exploit that trust to gain access to the 
business partner's resources, e.g. trick their browser into connecting to an 
internal resource on their network, that happens to have the same private 
address as what you published. Business partner trusts example.com (your 
domain), nat.example.com resolves to 10.1.1.1, malicious actor redirects a 
website reference to nat.example.com (which you trust) and this gives them 
unintentional, unauthorized access to 10.1.1.1 on business partner's network.

The basic Information Security problem with private addresses is that they are 
*non-unique*. This introduces ambiguity, and ambiguity produces surprises and 
can be exploited. Best to keep everything to do with private addresses and 
private namespaces within your own organization (and yes, I understand the 
general trend towards "eliminating the perimeter", but this needs to be done in 
a methodical, careful way).


- Kevin


-Original Message-
From: bind-users  On Behalf Of Greg Rivers
Sent: Friday, July 27, 2018 12:07 PM
To: Elias Pereira 
Cc: bind-users@lists.isc.org
Subject: Re: Authoritative dns with private IP for hostname

On Friday, July 27, 2018 12:59:42 Elias Pereira wrote:
> Can an authoritative dns for a domain, eg mydomain.tdl, have a 
> hostname, example, wordpress.mydomain.tdl with a private IP?
> 
Yes, but that won't be useful outside of your LAN.

> Would this be accessible from the internet via hostname, if I did a 
> nat on the firewall?
>
No, by definition, private addresses are not routable on the Internet.

--
Greg Rivers
___
Please visit https://lists.isc.org/mailman/listinfo/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: Domain name based multihome routing?

[Darcy Kevin (FCA)]

Yeah, but it's not an exact science, any way you slice it.

I just did a quick crunch of yesterday's data from our web proxy logs, and 
accesses of URIs based on the FQDN "b.scorecardresearch.com" (a banner ad site, 
I believe) had over 570 different combinations of website content categories, 
depending on URI. One FQDN, 570 different possible ways one might want to 
direct the traffic. DNS-based approaches simply may not have the granularity 
necessary to get the job done.

Speaking of web proxies, that should probably be the *first* thing that gets 
put into place, if the goal is minimize "disfavored" web traffic from 
traversing expensive WAN connections.


- Kevin


-Original Message-
From: bind-users  On Behalf Of Grant Taylor 
via bind-users
Sent: Wednesday, June 27, 2018 11:04 PM
Cc: bind-users@lists.isc.org
Subject: Re: Domain name based multihome routing?

On Jun 27, 2018, at 12:27 PM, Darcy Kevin (FCA)  
wrote:
> I’m not convinced DNS has any valuable role to play here.

I can see the value for services that have FQDNs that resolve to IP addresses 
outside of their ASN(s) like Google / YouTube.



-- 
Grant. . . .
unix || die
___
Please visit https://lists.isc.org/mailman/listinfo/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: Stopping name server abuse

[Darcy Kevin (FCA)]

IANAL, but even if one considers this scenario to constitute a DDoS attack, and 
there is plenty of case law supporting prosecution under CFAA (Computer Fraud 
and Abuse Act) for DDoS attacks, CFAA generally requires *intent*, and this 
appears to be simple negligence.

"Trespass to chattel" might be another possibility, but only as a civil (not 
criminal) complaint. And one would have to prove damages, which might be 
difficult to assess, or simply _de_minimis_.


- Kevin

-Original Message-
From: bind-users  On Behalf Of Barry Margolin
Sent: Tuesday, June 26, 2018 10:42 AM
To: comp-protocols-dns-b...@isc.org
Subject: Re: Stopping name server abuse

In article ,
 Paul Kosinski  wrote:

> Somebody who has irresponsibly (and apparently wantonly, given his 
> refusal to fix it) delegated his domain(s) to your DNS server is 
> essentially causing a (modest bandwidth) distributed denial of service 
> attack on your server. I don't think that the "responsible" thing to 
> do is to sit there and suffer from a significantly increased load.

Good luck getting him prosecuted under any kind of computer abuse law. 
That would be like calling the cops on a sibling who is poking you, claiming 
that it's assault.

> What should be done is to get the domain(s) revoked if the owner 
> continues to refuse to remedy the problem: it is *he*, not you, who is 
> being irresponsible. And if the queries are coming via an innocent 
> ISP's resolver, then they are inadvertently assisting in the attack, 
> and should be contacted and asked to help in the remediation. (Note 
> that *their* resources, as well as yours, are being wasted.)

I doubt any ISPs will do anything about it. It's probably negligible relative 
to their total DNS volume, and would be more trouble than it's worth to add 
filters to block it.

The domain registrar is the place to go, I expect most of them have standard 
procedures for exactly this problem.

--
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: DNS can be a subdomain

[Darcy Kevin (FCA)]

Domain Controllers certainly need to have their hostnames registered in the AD 
domain, but regular domain-joined members do *not*. We've been running AD for 
decades, without registering members in the AD domain. Works fine. Instead, we 
get our (non-Microsoft) DHCP servers to register dynamic clients automatically 
in a vendor-agnostic zone hosted on BIND (actually, Infoblox running modified 
BIND under the covers), and servers, whether Windows or not, get manually 
registered in various vendor-agnostic zones. The only hostnames in our AD 
domain are the Domain Controllers, and those hostnames are redundant with what 
exists in the vendor-agnostic zones. The reverse records point back to the 
vendor-agnostic-zone names.

Microsoft calls this architecture a "disjoint namespace", which is slightly 
derogatory. According to 
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/disjoint-namespace,
 disjoint namespaces are "more complex" (which is rich, coming from Microsoft, 
inventor of aging, scavenging and "tombstone records" for their DNS) and cites 
various caveats and disadvantages. But it's fully supported. I just had a word 
with one of our AD experts, and he reminded me that, with a disjoint namespace, 
you need to take some care to define the "disjointed" namespaces as being 
authorized for SPN generation (we did that a long time ago, and I had forgotten 
that step). But that's one of the few "gotchas" associated with disjoint 
namespaces.


- Kevin

-Original Message-
From: bind-users  On Behalf Of Grant Taylor 
via bind-users
Sent: Wednesday, June 27, 2018 12:35 AM
To: bind-users@lists.isc.org
Subject: Re: DNS can be a subdomain

On 06/26/2018 10:21 PM, Mark Andrews wrote:
> And if you are not using AD you can use SIG(0) and KEY records to 
> allow hosts to authenticate updates to the DNS for their own records.

I'm not quite following.  Do you mean that you can allow hosts to update their 
own RRs without requiring AD and using SIG(0) as an alternative?

Or are you saying forego AD (and Kerberos) and use SIG(0) instead?

#confused

> Instead of registering a host with AD you add a KEY record into the 
> DNS which has the public key of the host which is to be used to sign 
> the UPDATE requests.

If you're using AD for (presumably) Windows networking (and all that
entails) you very likely want the workstations to be registered with AD. 
  The machine trust accounts are pertinent to AD's operation and the 
workstation's ability to access AD resources when users aren't logged in.

#stillConfused

> Unfortunately OS developers have been asleep at the wheel by not 
> adding support for this to their products.

I'm seeing more and more references to SIG(0) in the last couple of weeks.  I 
think I need to refresh myself on it.



-- 
Grant. . . .
unix || die

___
Please visit https://lists.isc.org/mailman/listinfo/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: Domain name based multihome routing?

[Darcy Kevin (FCA)]

Traffic shaping is not my area of expertise, but from what I understand, at a 
minimum it can classify different kinds of traffic, based on more reliable 
metrics than DNS name. I was assuming (perhaps incorrectly), that its output 
(QoS markings or CoS or whatever) could then be used in a degenerate mode to 
force certain types of traffic over particular WAN connections, by manipulating 
costs, thresholds, etc.

In a quick scan, I found this article 
https://turbofuture.com/computers/How-to-Configure-Deep-Packet-Inspection-Using-pfSense
 (URL is misleading; the vast majority of the article isn’t about DPI at all). 
This shows a pfSense “wizard” that generates different profiles depending on 
your particular combination of single/multiple WANs and/or LANs. What I take 
from the guide is that the traffic shaping can know about your WAN setup and 
can be tweaked to push the traffic the way you want it to, over different WAN 
links.

I might be completely off-base on this, but it seems like a more fruitful line 
of research/inquiry than determining traffic profiles based on DNS names, and 
then hacking BIND to manipulate your routing table on-the-fly. That seems to me 
fraught with challenges, risks and limitations.



- Kevin


From: Dale Mahalko 
Sent: Wednesday, June 27, 2018 2:18 PM
To: Darcy Kevin (FCA) 
Cc: bind-users@lists.isc.org
Subject: Re: Domain name based multihome routing?

On Wed, Jun 27, 2018 at 12:27 PM, Darcy Kevin (FCA) 
mailto:kevin.da...@fcagroup.com>> wrote:
I’m not convinced DNS has any valuable role to play here. Seems like this is a 
traffic-shaping challenge; maybe one of the open source traffic shaping tools 
would fit the bill.

A Google search for multihome traffic shaping yields nothing obvious.

Do you have specific details you can share about exactly how that would be done?

Also how is traffic shaping going to tell the difference between a background 
Apple iOS update or Windows update that need to use the DSL, and the high 
priority data streams that are more important to me, that need to use the 
cellular modem?


Shaping is not routing, it just prioritizes some data streams over others. I 
don't see how shaping is going to know whether to use the DSL or the Cellular 
... without inspecting the domain name before a connection is established 
which is what I'm already discussing here...

___
Please visit https://lists.isc.org/mailman/listinfo/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: Domain name based multihome routing?

[Darcy Kevin (FCA)]

I’m not convinced DNS has any valuable role to play here. Seems like this is a 
traffic-shaping challenge; maybe one of the open source traffic shaping tools 
would fit the bill.



- Kevin


From: bind-users  On Behalf Of Dale Mahalko
Sent: Wednesday, June 27, 2018 1:00 PM
To: bind-users@lists.isc.org
Subject: Re: Domain name based multihome routing?

There is no way to know if this is the "right" or "wrong" approach without 
actually trying it and see what happens.

Guessing the potential background domains used by Microsoft / Steam, etc and 
monitoring bandwidth used by those domains is unfortunately the only option 
available. It's not like any of these companies are willing to outright divulge 
anything about these background details to anyone outside their business.

As far as load on the router goes for keeping track of possibly tens of 
thousands of custom routes, I am fine with dedicating a fast Intel i5 or i7 and 
a couple gigabytes of memory to the job. Most routers are tiny little things 
with very little CPU needed for normal routing, with the heavy lifting only 
happening if encryption is needed for a bunch of VPN connections.

On Wed, Jun 27, 2018 at 9:16 AM, Matus UHLAR - fantomas 
mailto:uh...@fantomas.sk>> wrote:
On Tue, Jun 26, 2018 at 12:45 PM, Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:
Are you saying that you want to dynamically update routes to IPs resolved
in real time to specific host / domain names?  Such that traffic to
specific hosts / domain names is routed over DSL?  With things that don't
match conditions routed over cell?

I think I understand what you want to do and why you want to do it.

It seems like you're using named as the source of information to feed into
the process that dynamically updates routing.

I find the pausing of named to be questionable.  But I understand that you
want to make sure that no connections are started until after the
(re)routing has been done.

On 26.06.18 14:07, Dale Mahalko wrote:
(I am no programming expert as mentioned, but I do IT stuff for a living,
so..)

The pause would only be long enough to look for a regex domain pattern to
be routed to the DSL, and then creating the route. This pause can likely be
measured in nanoseconds.

I don't think this could be done in nanoseconds. Maybe microseconds, but
more probably miliseconds.

Another question would be, how fast your router can be with potentially
thousands of routes (I know, many OSes have routing optimised very hardly).
This would likely be a multithreaded asynchronous mechanism so that BIND
does each of its lookups as usual, and then forks a followup thread after
it completes its normal lookup process, to do the pattern match and route
creation, followed by the delayed response released when the
pattern-match/route-creation thread terminates.

So in general using multithreading, there would be no real impact to
programs requesting the lookups, other than a delay per lookup that is so
small it would not be noticeable to an end-user human.

I think that you are trying wrong approach, using wrong tools.
Guessing the potential usage from DNS is not a goog idea.

On your router, configure firewall to route selected protocols (gaming, ssh,
RDP, dns) and maybe later some sites to paid cellular and router everything
other to DSL.

Note that at my home, most of data is spend by my children watching youtube
videos - I don't think that routing general web and streaming services to
cell connection would help you with anything.

--
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.
M$ Win's are shit, do not use it !

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

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

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

[Darcy Kevin (FCA)]

“We are aware that we should not mix the plain text configuration with these 
dynamic records (and use a subdomain instead)”

So, why don’t you do that? As far as I know, Domain Controllers still only 
maintain SRV records, so the “underscore zones” approach should still work. 
Make _tcp.example.com, _udp.example.com, _msdcs.example.com, etc. separate 
subzones, with Dynamic Updates allowed (for the Domain Controllers to 
add/delete/refresh their SRV records), and have the main zone (example.com) 
maintained by FusionDirectory. No need to get fancy with LDAP backends…




- Kevin


From: bind-users  On Behalf Of Jérôme BECOT
Sent: Wednesday, May 02, 2018 9:49 AM
To: bind-users@lists.isc.org
Subject: Dynamic zone vs static records

Hello,

We are managing our DNS zone within LDAP through a 3rd party editor 
(FusionDirectory). This software is configured to export the LDAP configuration 
to plain text zone files, updated on the master (and a zone reload is made by 
the software by calling rndc).

If we make this zone dynamic we have a serial issue because each server (Acitve 
Directory) dynamically updating the zone increments the serial which do not 
update the LDAP. Refreshing the zone via FusionDirectory do not work as the 
generated serial is lower.

We are aware that we should not mix the plain text configuration with these 
dynamic records (and use a subdomain instead). As we want to edit the zone in 
LDAP and we would like to make the AD servers autoregister their record in the 
zone, would using bind with the LDAP backend allow us to do so ? 
(FusionDirectory can be configured as a simple LDAP editor without pushing text 
config).

Let me know if my question is odd or lacking of information.

Thank you for your further advices.

JEROME BECOT
Ingénieur Système et Réseau
DSIRN
Bureau n°4.29

Institut national des langues et civilisations orientales
65 rue des Grands Moulins
Paris 75013, France

01 81 70 10 78
jerome.be...@inalco.fr
www.inalco.fr
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

RE: BIND 9.9 cannot resolve PTR record but +trace can

[Darcy Kevin (FCA)]

On a case-by-case basis, one can use stub zones, conditional forwarding, etc. 
but if you're looking for a "break Internet standards" switch, I think you're 
going to be disappointed. Vix has stopped calling BIND a "reference" 
implementation of DNS, but it still tries to set a good example.


- Kevin



-Original Message-
From: bind-users  On Behalf Of Aras Yorganci
Sent: Wednesday, April 11, 2018 9:49 AM
To: Anand Buddhdev 
Cc: bind-users@lists.isc.org
Subject: Re: BIND 9.9 cannot resolve PTR record but +trace can


Alinti Anand Buddhdev 

> The delegation of 131.161.213.in-addr.arpa points to dns.est.com.tr 
> and dns2.est.com.tr. But these two names are aliased to 
> dns3.est.com.tr and dns4.est.com.tr.
>
> However, one cannot use alias names as targets of NS records. This is 
> forbidden by RFC 2181, section 10.3.
>
> The operator of this reverse zone (EST Bilisim) should update the 
> delegation of 131.161.213.in-addr.arpa (in the RIPE Database) and use 
> the proper name servers names in there. If you know someone there, 
> please inform them.
>
> Regards,
> Anand
>
> On 11/04/2018 15:23, Aras Yorgancı wrote:

Thanks for reply. I understand that there is an illegal situation but other dns 
servers can resolve this query while BIND cannot. Maybe I have not much 
knowledge about subject but I wonder is there any way or any configuration to 
resolve this query with my BIND server, bypass this prohibition?

Regards,
Aras

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

[Darcy Kevin (FCA)]

"Stealth" implies something that isn't seen in the normal course of activity, 
so it's really the *wrong* word to use here, since the apex NS records are seen 
during normal iterative resolution, and in fact the apex NS records take 
precedence over the delegated NS records in the sense of RFC 2181 data-ranking. 
So, to call them "stealth" seems mistaken, and misleading.

A better term than "stealth NS" would be "mismatched NS". From an 
integrity-check perspective, IMO the mismatch condition should be flagged as 
questionable if the apex NS records are a superset of the delegated ones, and 
worrisome if completely disjoint.


- Kevin



-Original Message-
From: bind-users  On Behalf Of Matus UHLAR - 
fantomas
Sent: Friday, March 30, 2018 4:27 AM
To: bind-users@lists.isc.org
Subject: Re: Stealth NS records

On 30.03.18 15:44, PANG J. wrote:
>I saw a zone check on intodns.com shows,
>
>Stealth NS records were sent:
>ns2.xxx.com
>ns1.xxx.com
>
>So what's a stealth NS record?

http://massivedns.com/blog/dns-report-tutorials/what-are-stealth-ns-records/

maybe I could explain more deeply if you have sent the domain.

-- 
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.
Linux IS user friendly, it's just selective who its friends are...
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/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: GSS-TSIG update-policy clarification

[Darcy Kevin (FCA)]

Why are you letting the clients register their own addresses in DNS in the 
first place? If you want a higher level of control, move the DDNS 
responsibility to the DHCP server.


- Kevin


-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Nicholas Miller
Sent: Friday, March 23, 2018 4:16 PM
To: bind-users@lists.isc.org
Subject: Re: GSS-TSIG update-policy clarification

Thats well and good for an organization that controls ALL of the end points. In 
a university that isn’t possible. 
_
Nicholas Miller, OIT, University of Colorado at Boulder

> On Mar 23, 2018, at 2:04 PM, Mark Andrews  wrote:
> 
> If you don’t want 6to4 addresses stop the machine configuring them. 
> 
> Not everything should be done at the DNS level.
> --
> Mark Andrews
> 
>> On 24 Mar 2018, at 01:07, Nicholas Miller  
>> wrote:
>> 
>> As a followup, is there a way to stop Windows systems from adding their 
>> 6-to-4  record? I see little point in adding these records to a domain.
>> _
>> Nicholas Miller, OIT, University of Colorado at Boulder
>> 
>>> On Mar 22, 2018, at 12:13 PM, Mark Andrews  wrote:
>>> 
>>> This was noted in the release notes and in CHANGES.
>>> 
>>> 4885.   [security]  update-policy rules that otherwise ignore the name
>>>  field now require that it be set to "." to ensure
>>>  that any type list present is properly interpreted.
>>>  [RT #47126]
>>> 
>>> krb5-subdomain gets the permitted names from the Kerberos credential 
>>> name (host/machine@REALM).
>>> 
 On 23 Mar 2018, at 2:50 am, Nicholas Miller  
 wrote:
 
 With the latest update to bind our named.conf started reporting errors. I 
 have figured it out but wanted to get clarification about the syntax.
 
 We had been using:
 
   deny DOMAIN.EDU krb5-subdomain DOMAIN.EDU CNAME MX SRV TXT;
 
 We are now using:
 
   deny DOMAIN.EDU krb5-subdomain . CNAME MX SRV TXT;
 
 Am I to assume that the ‘.’ in the config statement behaves similarly to 
 the ‘.’ in a zone file? It refers back to the zone the update-policy is 
 defining?
 
 Also, what is the difference between using a ‘.’ and a ‘*’? They both 
 refer to all records within the zone.:
 
   deny DOMAIN.EDU krb5-subdomain * MX SRV TXT;
 
 _
 Nicholas Miller, OIT, University of Colorado at Boulder
 
 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
 unsubscribe from this list
 
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
>>> 
>>> --
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>>> 
>> 
> 

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

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

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

RE: baby steps...

[Darcy Kevin (FCA)]

We're getting a little afar of DNS and BIND here, since this is OS networking 
configuration stuff, made slightly more complicated by the fact that (as far as 
I can see) you didn't specific what OS and/or distro you're running.

So let's get generic.

Google'ing "pppd override resolvers". First hit:

https://unix.stackexchange.com/questions/90035/how-to-set-dns-resolver-in-fedora-using-network-manager

(Despite the question being specifically about Fedora, there are answers in the 
thread for other distros, and one detailed response titled "PPPD Scenario". 
There are other hits for that Google search as well).


- Kevin


-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Adam 
Hardy
Sent: Thursday, March 22, 2018 6:54 PM
To: bind-users@lists.isc.org
Subject: Re: baby steps...

 I set up my SOHO server to be a router/gateway to the net, firewall, DHCP 
 server, DNS server and backup server for my lan.

 I set up bind9 and isc-dhcp to support DDNS, but I am struggling to get 
 hostname resolution working on the  server for the lan clients.

 The server has two NICs - one for lan on 192.168.0.3, and one that obtains 
 its public IP address via pppoe from the broadband provider (which 
 shouldn't be serving DNS outwards but needs configuring not to).
>>>
>>> options {
>>>listen-on { 198.158/16; 127.0.0.1; };
>>>listen-on-v6 { ; ::1; }; };
>> So that will tell bind to serve 127.0.0.1, but don't I need to 
>> configure linux to go to 127.0.0.1 for DNS, since at the moment it 
>> isn't, according to resolv.conf, it's going to the OpenDNS servers:
 >>
>> adam@gondor:~$ cat /etc/resolv.conf
>> nameserver 81.139.56.100
>> nameserver 81.139.57.100
>> domain localdomain
>> search localdomain
>> adam@gondor:~$
>> 
>> and that is generated by pppd when it connects.  I'm guessing now but 
>> presumably I have to tell pppd to add 127.0.0.1 to the other 
>> nameservers - the server wants to see the lan as well as the outside world.
> 
> So you configure your lan-side NIC to use localhost (or its own
> ip-address) as first dns. Nothing to do with bind.

nnnnnn trying to understand nnfg

Nope, can't.



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

[Darcy Kevin (FCA)]

Call me a contrarian, but I've never really signed onto the conventional wisdom 
that recursive and authoritative roles should never be mixed, even as I've 
transitioned into the InfoSec realm, where, generally speaking, we are quite 
wary of mixing roles within a single service (more software complexity leads to 
higher probability of defects, a bigger attack surface, and so on).

Other than the master server(s), where there is no choice but to be 
authoritative, at one end of the spectrum, and border resolvers, for which 
there is no choice but to be non-authoritative (since it's not practical to 
replicate data for the vast diversity of namespaces on the Internet in which to 
resolve queries), at the other end of the spectrum, there is a middle ground, 
where there is a real *choice* as to whether to be authoritative (i.e. a slave, 
possibly a "stealth slave") for internal zones or not. The decision of whether 
to be authoritative or not, is driven by a number of factors, such as 
worst-case-query-performance sensitivity, availability requirements, 
query-frequency-versus-refresh-overhead, available bandwidth, DNSSEC, etc. It 
is perfectly reasonable, architecturally, for a given DNS instance to be a 
stealth slave for some zones and to either delegate, stub and/or forward for 
other zones, or for the default to be one or the other (auth-server as default 
implies having an internal root). Different zones have different requirements, 
different use cases, query patterns, etc. so why wouldn't a choice of different 
configurations for different zones be appropriate?

Now, as a matter of *implementation*, it might be useful, and arguably more 
secure, for these -- auth-server versus resolver -- to be separate software 
modules. But the modules should be able to co-exist on the same listener. 
Whether a given request gets dispatched to a different process or thread, 
depending on whether it is to be satisfied from authoritative data, or if 
iterative resolution (or forwarding) is required, is, again, a matter of 
implementation. But the choice to mix authoritative and non-authoritative on 
the same listener, should IMO remain available. Otherwise, you're forcing 
inappropriate choices on people -- e.g. slaving when it isn't really needed and 
could be considered overkill, or iterative/recursive resolution where slaving 
would be preferable from a performance, availability or other perspective.

As for BIND 10, it looks pretty dead, to me. According to ISC's website, they 
concluded work on it, including an authoritative server module, and handed it 
off to the Open Source community, where it became "Bundy". But 
http://bundy-dns.de/ doesn't seem to have been updated since 2014. So, I 
wouldn't hold my breath on a full-featured BIND 10 or "Bundy" DNS 
implementation any time soon...


- Kevin



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark 
Elkins
Sent: Tuesday, February 20, 2018 2:58 AM
To: bind-users@lists.isc.org
Subject: Re: questions on allow-query

Reading between the lines - it sounds like you may be mixing nameserver roles, 
recursion with authoritative.

This is not a good idea and is why other Nameserver software (NSD, UNBOUND and 
others) either perform one role or the other. I understand that BIND-10 was 
also designed like this - separate software modules for the two separate roles.

Then your "access list" is simple.


Recursive: Starts with knowing next to nothing, can be asked for anything and 
serves a restrictive population acl "trusted" {
    127.0.0.0/8;
    ::1/128;
    192.X.X.0/24;
    2001:::::/48;
  };
allow-query { trusted; };
allow-recursion { trusted; };


Authoritative: Starts with knowing everything about just a few Domains, can 
only be asked about what it knows and serves the World.
allow-query { any; };
allow-recursion { none; };

You'll otherwise find that things like DNSSEC don't work as expected.


On 20/02/2018 00:51, @lbutlr wrote:
> If I set
>
> allow-query { 127.0.0.1; [myipblock]; }
>
> Then my DNS doesn't respond to any other servers, right? This would be bad 
> for being authoritative. so, should I set that and then set allow-query { 
> any; }; in each zone?
>
> Is that better than simply setting the IPs that are allowed recursion?
>
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

--
Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

RE: Question abut reserv zone

[Darcy Kevin (FCA)]

You mean, don't slave 100.10.in-addr.arpa at all, and just maintain 
10.in-addr.arpa locally?

The problem the original poster may run into, however, is that there may be 
other records in 100.10.in-addr.arpa that change dynamically, and those changes 
may not be reflected if only 10.in-addr.arpa is maintained locally.

To be sure, a "sync" script could be run periodically to keep 10.in-addr.arpa 
up to date. I've written such things in the past. But now we're talking about 
custom software, not something that can be accomplished using just BIND and its 
associated tools...

The other approach is to define zones for just the specific names that need to 
be "overridden" from the slave zone (Microsoft calls them "pinpoint zones"). 
That's a terrible solution, of course, since these zones are undelegated from 
their parent and thus special care must be taken to ensure that all resolvers 
which need to resolve the names in a specific way are configured appropriately 
(using master/slave/stub/forward). But at least it can be implemented using 
only BIND and its tools.


- Kevin




-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark 
Andrews
Sent: Monday, February 12, 2018 6:19 PM
To: Julie Xu 
Cc: bind-users@lists.isc.org
Subject: Re: Question abut reserv zone

In this example since the address is the same I would just pick one name (the 
name the machine knows itself as) and use that name for the PTR record.

I would also use DNS UPDATE to update the reverse zones rather than editing 
master files.  You can delegate update authority down to the  tuple 
level with DNS UPDATE.  Then it doesn’t matter which machines are holding 
master files for the reverse zones.

Mark

> On 13 Feb 2018, at 9:06 am, Julie Xu  wrote:
> 
>> 
>> Hi,
>>  
>> I have a zone, we say abc.edu.au, all private address 10.0.0.0/8 is in this 
>> zone. So, I have a revers zoon 10.in-addr-arpa existed. I am the master.
>>  
>> Now, there is a new zone required - ddd.abc.edu.au reverse should 
>> 100.10.in-addr-arpa; we are secondary of this zone.
>>  
>> However, currently, there is some ip address in zone abc.edu.au there which 
>> is  the range, they are still required.
>>  
>> For example we want host.ddd.abc.edu.au, and app.abc.edu.au both existed. 
>> The host.ddd.abs.edu.au – 10.100.10.20 – transferred from 
>> master dns for the domain ( both forward/reversed zones)
>> The app.abc.edu.au – 10.100.10.20  original in 10.0.0.0/8 
>> zone file which we are the master.
> 
> Both are A record.
>>  
>> What will happen if I create second reverse zoon for 100.10.in-addr-arp? Is 
>> my current app.abc.edu.au will lose? If it is true, do I have anyway to work 
>> around?
>>  
>> Any comments will be appreciated
>>  
>> Thanks in advance
>>  
>>  
>> Julie Xu
>>  
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
> unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

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

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

RE: question

[Darcy Kevin (FCA)]

Are you asking about the search algorithm in *DNS* (hierarchical, labelwise 
exact match, with aliasing and wildcarding special cases), or the algorithm by 
which *BIND* -- as one *implementation* of DNS -- accesses data in its internal 
structures (modified red-black tree, IIRC)?






- Kevin

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Munhbaatar Doctor via bind-users
Sent: Wednesday, November 08, 2017 7:55 PM
To: bind-users@lists.isc.org
Subject: question

I am Munkhbaatar, a master course student studying on mechanism and algorithm 
of DNS.
I want to search algorithm in DNS, but i have not found the documents clearly 
explaining this on the web.
I guess it's just a "list search", but I am not sure.
Please tell me the details of the search algorithm.

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

[Darcy Kevin (FCA)]

You can certainly configure the subdomains that way, but the same resolver 
which followed the subdomain.example.com delegation in the first place, to your 
BIND instance, will presumably follow the delegation of 
sub.subdomain.example.com (as it is published via NS records in the parent 
zone) to find the nameservers for that subzone, query them, and expect 
authoritative responses. Your forwarding config won't be used, by such a 
resolver, since it'll be sending you non-recursive (RD=0) queries, which are 
incompatible with forwarding.

Ultimately, the bottom line is that if the "leaf-node" data is not available in 
an authoritative form, then you can't use delegation alone to facilitate its 
resolution. You'd need to set up some sort of forwarding, possibly multi-hop 
forwarding, which is notorious for being fragile, inefficient and lacking in 
scalability.

You mentioned in another post that the DNS data in question is for a cloud 
environment. My experience so far (primarily with AWS) is that these cloud 
providers don't understand how robust DNS enterprise architectures work. If 
they did, they would have offered authoritative, replicate-able DNS zone data 
as a basic service, straight out of the gate. Supposedly this "feature" is "on 
the roadmap" for AWS, but it seems to be a distant goal, with no particular 
priority. In the meantime, they are requiring their enterprise customers to 
sacrifice some of the reliability and performance we've built up in our DNS 
infrastructures over years (and, in some cases, decades), instead stringing 
together forwarding hierarchies and other nonsense like that.

(Editorial note: I originally got carried away at this point, explaining my 
model of how DNS is, conceptually, constructed -- authoritative core, inner 
iterative-resolution layer, outer recursive-resolution layer -- along with a 
diatribe about how poor/junior enterprise DNS architects try, with sub-optimal 
results, to build on recursive resolution as a foundation, because that's the 
only layer they really understand. But I don't want to put anyone to sleep, or 
fill up their mailboxes with walls of text, so I'll forego that for now, saving 
the text for some other day). 

May I ask: why would you put anything non-AD-related, of actual importance, in 
a *subdomain* of an Active Directory zone ? Maybe it's just a matter of 
perspective, but I see Active Directory as just one service we run in our 
enterprise, among many. So, while it gets its own namespace, it doesn't get to 
control the *main* namespace -- certainly, we would never put anything 
non-AD-related *underneath* an AD zone. Granted, I don't know your 
organization's structure, internal politics, history, etc. But it just seems 
rather odd to me that you're delegating stuff from an AD zone. I view such 
namespaces as "leaves", not "branches".


- Kevin


-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
seanliam73
Sent: Wednesday, October 11, 2017 3:45 AM
To: bind-users@lists.isc.org
Subject: RE: Forwarding from delegated zone not working

Thanks Kevin

That is what I suspected. If I make the delegated server the master/slave for 
the sub-domain that has been delegated, could I then set up forward zones for 
further sub-domains? i.e

subdomain.example.com (delegated domain set as master zone) 
sub.subdomain.example.com (forward zone)

Sean



--
Sent from: http://bind-users-forum.2342410.n4.nabble.com/
___
Please visit https://lists.isc.org/mailman/listinfo/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 from delegated zone not working

[Darcy Kevin (FCA)]

But surely you’d get an NXDOMAIN in that case, not a SERVFAIL.

The assumption I made in my post was that the delegation was pointed to the 
forwarding BIND instance, which is a non-starter.


-  Kevin


From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ben 
Croswell
Sent: Tuesday, October 10, 2017 11:38 AM
To: seanliam73 
Cc: bind-users@lists.isc.org
Subject: Re: Forwarding from delegated zone not working

If the AD environment loads company.com you need to make 
sure it has NS delegations. The nameserver will ignore the zone forwarded if it 
knows the child doesn't exist.

On Oct 10, 2017 11:22 AM, "seanliam73" 
> wrote:
Hi

I have a subdomain delegated from AD to a bind9 instance I have running that
so that all requests for that subdomain are sent to the bind 9 instance. I
would then like to set up zone forwarding so that further subdomains can be
managed by other bind 9 instances.

I know the forwarding is working because I can query the main bind9 instance
at receive the expected results. However if I query from the AD server that
is doing the delegation I get a SERVFAIL error.

Am I trying to do something that is not possible or am I just missing some
configuration.

*main instance config*

options {
directory "/var/named";
listen-on port 53 { listen addr; };
auth-nxdomain yes;
recursion yes;
allow-query { ip addresses; };
listen-on-v6 { any; };
dnssec-enable no;
dnssec-validation no;
dnssec-lookaside auto;
};

logging {
channel default_debug {
file "data/named.run";
severity debug 3;
};

channel querylog {
file "data/query.log";
severity debug 5;
};

category default { default_debug; };
category queries { querylog; };
};

zone "example.company.com" IN {
type forward;
forward only;
forwarders { ip address; };
};

zone "development.example.company.com" 
IN {
type forward;
forward only;
forwarders { ip address; };
};



--
Sent from: http://bind-users-forum.2342410.n4.nabble.com/
___
Please visit https://lists.isc.org/mailman/listinfo/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 from delegated zone not working

[Darcy Kevin (FCA)]

It doesn't work to delegate to a forwarder; you have to delegate to something 
that's authoritative for the zone (master or slave). Delegated nameservers are 
expected to have a full copy of the zone, either as the source (master) or 
through replication (slave).

Now, if you have restrictions/limitations that prevent you both from a) 
delegating directly from AD to the authoritative nameservers, and b) 
replicating from the authoritative nameservers to the BIND instance in 
question, then you'd need to look into some sort of "DNS proxy", but that's not 
BIND, and really beyond the scope of this list.


- Kevin

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
seanliam73
Sent: Tuesday, October 10, 2017 11:22 AM
To: bind-users@lists.isc.org
Subject: Forwarding from delegated zone not working

Hi

I have a subdomain delegated from AD to a bind9 instance I have running that so 
that all requests for that subdomain are sent to the bind 9 instance. I would 
then like to set up zone forwarding so that further subdomains can be managed 
by other bind 9 instances.

I know the forwarding is working because I can query the main bind9 instance at 
receive the expected results. However if I query from the AD server that is 
doing the delegation I get a SERVFAIL error.

Am I trying to do something that is not possible or am I just missing some 
configuration.

*main instance config* 

options {
directory "/var/named";
listen-on port 53 { listen addr; };
auth-nxdomain yes;
recursion yes;
allow-query { ip addresses; };
listen-on-v6 { any; };
dnssec-enable no;
dnssec-validation no;
dnssec-lookaside auto;
};

logging {
channel default_debug {
file "data/named.run";
severity debug 3;
};

channel querylog {
file "data/query.log";
severity debug 5;
};

category default { default_debug; };
category queries { querylog; };
};

zone "example.company.com" IN {
type forward;
forward only;
forwarders { ip address; };
};

zone "development.example.company.com" IN {
type forward;
forward only;
forwarders { ip address; };
};



--
Sent from: http://bind-users-forum.2342410.n4.nabble.com/
___
Please visit https://lists.isc.org/mailman/listinfo/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: Differences Between Recursion Desired and Recursion Available

[Darcy Kevin (FCA)]

For this reason, "stub" resolvers typically set RD=1, and only "full-service 
resolvers", such as the one integrated into named (although there are 
standalone ones, like Knot, Unbound, [1]), generate RD=0 queries. Full-service 
resolvers are capable of taking the referrals, and using them to follow the 
delegation chain all of the way down to an authoritative nameserver that can 
give a definitive answer. Stub resolvers are a lot dumber -- they just send a 
query and process the response, without a lot of referral-chasing, RTT-based 
nameserver selection, data ranking and so forth. RFC 1034, Section 5.3.1, 
describes stub resolvers, and RFC 1123, Section 6.1.3.1, briefly describes the 
difference between stub resolvers and full-service resolvers.

If a stub resolver gets a referral, because of a misconfiguration, policy-based 
denial of recursion by an upstream resolver, or for whatever reason, it'll pass 
that back to the invoker as "no answer". It's not smart enough to dig deeper 
and find the answer. That takes code, and resources, and defeats the whole 
purpose of being a "stub" resolver, which is supposed to be relatively 
lightweight. Most platforms have added name caching, as a performance 
optimization, either directly embedded into the OS (e.g. Windows) or as a 
separate daemon/service (e.g. nscd). This makes the stub resolver seem smarter 
than originally envisioned, but under the covers, it's still just a single 
query/response mechanism (albeit with failover/retry capability), and thus 
referrals aren't useful to it.

It should be noted that answering from cache, e.g. when a server gets an RD=0 
query, or if it doesn't happen to honor recursion for that particular client, 
was originally (perhaps naively) unrestricted, but, given evolving 
privacy/security concerns, is now restricted by default, in all (or almost all) 
implementations. For BIND, it's controlled by allow-query-cache.


- Kevin

[1] One full-service resolver not mentioned above is "dnscache", part of the 
djbdns package. I call this out separately because DNSSEC is against DJB's 
religion (apparently), so this software will likely never support DNSSEC 
validation.

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Barry 
Margolin
Sent: Friday, October 06, 2017 12:47 PM
To: comp-protocols-dns-b...@isc.org
Subject: Re: Differences Between Recursion Desired and Recursion Available

In article ,
 Harshith Mulky  wrote:

> What I am not able to understand is, What would happen when resolver 
> does not set Recursion Desired bit in the query it sends?

If RD is not set, the server should simply not recurse. It answers with 
whatever it has in its cache or authoritative data. If it has the answer, it 
sends that; otherwise, if it has referral data, it sends that.

--
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: SOA serial increment when we update SOA RR

[Darcy Kevin (FCA)]

Well, it's not *obvious* how Dynamic Update works in the case of an SOA RR, but 
RFC 2136 does say:

3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
   the zone.  In case of duplicate RDATAs (which for SOA RRs is always
   the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
   fields both match), the Zone RR is replaced by Update RR.  If the
   TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
   lower (according to [RFC1982]) than or equal to the current Zone SOA
   RR's SOA.SERIAL, the Update RR is ignored.

So, the server ignores the update if the serial number of the new one is equal 
or lower. If the serial number is higher, the new SOA replaces the old one.

Bottom line: you can explicitly bump the serial number of an SOA RR, via 
Dynamic Update, by replacing the SOA RR with one that has a higher serial 
number.

In nsupdate terms, this is an "update add" operation, even though the effect is 
intended to be a "replace".


-  Kevin

[FCA_Pantone_email]
--
Kevin Darcy
Information Security Projects - North America

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Alberto 
Colosi
Sent: Wednesday, October 04, 2017 8:16 AM
To: rams ; bind-users 
Subject: Re: SOA serial increment when we update SOA RR


SOA is a special record. As already said to read 



you update SOA (should be only for email address if not ONLY intranet NS).



In all case if u make n update mean is needed n update. So the question is: 
  wy to not reflect on slave NSif any



Increasing SN , start a NOTIFY to NS defined as slave and ALSO NOTIFY.



If n update is made and r slaves or a distribution recursive and 
secondary(slave) and so on, is correct to update and start a ZONE TRANSFER.



If u hve only 1 DNS at all and is not internet faced, u can decide to not 
update SN



Simply , the change start an incremental transer o a total transfer (depending 
on DNS engine on slaves NS and also notify)










From: bind-users 
> on 
behalf of rams >
Sent: Wednesday, October 4, 2017 11:39 AM
To: bind-users
Subject: SOA serial increment when we update SOA RR

Greetings!!
When we change any resource record like A or , then SOA serial number gets 
incremented. But If we update only SOA record ,Is serial number of SOA remain 
same as before or serial number of SOA will increment?.

Do we have any RFC for this?

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

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

RE: What is wrong with my second $ORIGIN

[Darcy Kevin (FCA)]

Just as a general piece of advice, if you're trying to troubleshoot a zonefile 
parsing issue, sometimes it's useful to just do a zone transfer of the loaded 
zone and eyeball it. This is obviously more practical with a smaller zone (such 
as the one you showed) than a huge one, but even if the zone is large, you can 
focus on only the specific names/RRsets that you consider problematic.

In this case, a zone transfer would have shown the $ORIGIN being appended to 
the name in the input file which was missing the trailing period. It should 
have stuck out like a sore thumb, as they say, because the name would have been 
long and strange-looking. Sometimes that's a really quick way to home in on the 
problem than to stare at the input zone file and mimic the zonefile-parsing 
algorithm in one's head.

Of course, this assumes the zone loaded at all. It's possible to mess up a 
zonefile so much that it doesn't even load, but, in such cases, BIND usually 
gives a very specific error message about what's wrong. So those don't tend to 
lead to "mysteries" like the more subtle errors do (e.g. trailing-period 
omissions).


- Kevin



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Harshith Mulky
Sent: Friday, September 15, 2017 4:16 AM
To: bind-users@lists.isc.org
Subject: Re: What is wrong with my second $ORIGIN

Than you All.

Did not notice I had missed a trailing '.' 

Will make sure I do not miss these things the next time I test



--
Sent from: http://bind-users-forum.2342410.n4.nabble.com/
___
Please visit https://lists.isc.org/mailman/listinfo/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 to look up short names

[Darcy Kevin (FCA)]

Appending suffixes to short names to make them legal DNS names, is considered 
the responsibility of the *client*, not the *server*.

Look up “resolver search list” (more Unix-ish/Linux-ish) or “suffix search 
list” (more Windows-ish), and you should find some useful information.


-  Kevin


From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
toddandmargo
Sent: Thursday, August 10, 2017 8:21 PM
To: bind-users@lists.isc.org
Subject: need to look up short names


Hi All,

Fedora 26
bind-chroot-9.11.1-2.P2.fc26.x86_64

I am stumped.   I need to be able to look up short names on my local network.

Long names work:

# host pop3.xxx.local
pop3.xxx.local is an alias for FedoraServer.xxx.local.
FedoraServer.xxx.local has address 192.168.255.12

But not short names:

# host pop3
Host pop3 not found: 3(NXDOMAIN)

My hosts.xxx look like this for pop3:
FedoraServerA   192.168.255.12
pop3CNAME   FedoraServer

What am I missing?

Many thanks,
-T
___
Please visit https://lists.isc.org/mailman/listinfo/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-chroot, runs, works, dies

[Darcy Kevin (FCA)]

Your point is taken, I looked at a very old Redhat system, although I'll note 
that the pathnames under a chroot are not subject to the technical limitations 
you mentioned.

- Kevin


-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Reindl 
Harald
Sent: Wednesday, August 09, 2017 6:48 PM
To: bind-users@lists.isc.org
Subject: Re: bind-chroot, runs, works, dies



Am 10.08.2017 um 00:35 schrieb Darcy Kevin (FCA):
> I’m not very familiar with Fedora, but on Redhat, at least, there is 
> no /run directory

don't get me wrong but you are missing some years - /run is a important part of 
the system for a long time because it is a) tmpfs and b) available at early 
boot while /var maybe a later mounted filesystem

https://unix.stackexchange.com/questions/13972/what-is-this-new-run-filesystem

[root@hosting:~]$ stat /run
   File: '/run'
   Size: 560 Blocks: 0  IO Block: 4096   directory
Device: 11h/17d Inode: 9222Links: 22
Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2017-07-19 10:51:46.5 +0200
Modify: 2017-08-09 03:44:16.083351213 +0200
Change: 2017-08-09 03:44:16.083351213 +0200
  Birth: -
[root@hosting:~]$ rpm -q --file /run
filesystem-3.2-21.el7.x86_64

[root@hosting:~]$ cat /etc/redhat-release CentOS Linux release 7.3.1611 (Core) 
___
Please visit https://lists.isc.org/mailman/listinfo/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-chroot, runs, works, dies

[Darcy Kevin (FCA)]

I’m not very familiar with Fedora, but on Redhat, at least, there is no /run 
directory. Which makes me think that “/var/named/chroot/run/named/named.pid” is 
a misconfiguration. That would be seen as “/run/named/named.pid” from *within* 
the chroot. Following usual conventions, I think you probably meant to specify 
“/var/run/named/named.pid” in named.conf, didn’t you? The full, pre-chroot’ed 
path would then presumably be /var/named/chroot/var/run/named/named.pid.


-Kevin


From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
toddandmargo
Sent: Wednesday, August 09, 2017 6:14 PM
To: bind-users@lists.isc.org
Subject: bind-chroot, runs, works, dies


Hi All,

Help!

Fedora 26 x64
Xfce 4.12

# rpm -qa \bind\*
bind-libs-lite-9.11.1-2.P2.fc26.x86_64
bind99-libs-9.9.10-1.P2.fc26.x86_64
bind-chroot-9.11.1-2.P2.fc26.x86_64
bind-license-9.11.1-2.P2.fc26.noarch
bind-9.11.1-2.P2.fc26.x86_64
bind-libs-9.11.1-2.P2.fc26.x86_64
bind99-license-9.9.10-1.P2.fc26.noarch
bind-utils-9.11.1-2.P2.fc26.x86_64

I have a weird one. I am trying to set up bind-chroot. When I run it, it works

for about 30 seconds, then dies. And for the entire 30 seconds, it works

beautifully. I can go anywhere with Firefox and look up anything with "host". 
Then it breaks my heart.

# systemctl start named-chroot Job for named-chroot.service canceled.

This is my error logs:

Aug  8 15:58:49 FedoraServer named[10120]: all zones loaded Aug  8 15:58:49 
FedoraServer named[10120]: running Aug  8 15:58:49 FedoraServer named[10120]: 
zone 255.168.192.in-addr.arpa/IN: sending notifies (serial 57) Aug  8 15:58:49 
FedoraServer named[10120]: zone alpine.local/IN: sending notifies (serial 60) 
Aug  8 15:58:49 FedoraServer systemd: named-chroot.service: PID file 
/var/named/chroot/run/named/named.pid not readable (yet?) after start: No such 
file or directory  Aug  8 16:00:19 FedoraServer systemd: named-chroot.service: 
Start operation timed out. Terminating. Aug  8 16:00:19 FedoraServer 
named[10120]: shutting down Aug  8 16:00:19 FedoraServer named[10120]: stopping 
command channel on 127.0.0.1#953 Aug  8 16:00:19 FedoraServer named[10120]: 
stopping command channel on ::1#953 Aug  8 16:00:19 FedoraServer named[10120]: 
no longer listening on ::#53 Aug  8 16:00:19 FedoraServer named[10120]: no 
longer listening on 127.0.0.1#53 Aug  8 16:00:19 FedoraServer named[10120]: no 
longer listening on 50.124.80.106#53 Aug  8 16:00:19 FedoraServer named[10120]: 
exiting Aug  8 16:00:19 FedoraServer systemd: Stopped Berkeley Internet Name 
Domain (DNS). Aug  8 16:00:19 FedoraServer systemd: named-chroot.service: Unit 
entered failed state. Aug  8 16:00:19 FedoraServer systemd: 
named-chroot.service: Failed with result 'timeout'. Aug  8 16:00:19 
FedoraServer systemd: Stopping Set-up/destroy chroot environment for named 
(DNS)... Aug  8 16:00:19 FedoraServer audit: SERVICE_START pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 
msg='unit=named-chroot comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? 
addr=? terminal=? res=failed' Aug  8 16:00:20 FedoraServer systemd: Stopped 
Set-up/destroy chroot environment for named (DNS). Aug  8 16:00:20 FedoraServer 
audit: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 
subj=system_u:system_r:init_t:s0 msg='unit=named-chroot-setup comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

I find the

PID file /var/named/chroot/run/named/named.pid not readable (yet?) after start: 
No such file or directory

error to be a bit weird as the directory does exist and the entire directory 
tree from /var/named is owned by "named". This is usually SELinux's doing. But 
SELinux does not throw an error.

My "named.conf":

// generated by named-bootconf.pl  options { # the following forwarders 
is for Open DNS forwarders { 208.67.222.222; 208.67.220.220; }; 
directory "/var/named"; # pid-file 
"/var/named/chroot/run/named/named.pid"; # pid-file 
"/var/named/chroot/run/named/nonamed.pid"; /*  * If there is a firewall 
between you and nameservers you want  * to talk to, you might need to 
uncomment the query-source  * directive below.  Previous versions of BIND 
always asked  * questions using port 53, but BIND 8.1 uses an unprivileged  
* port by default.  */ // query-source address * port 53; };  //  
// /etc/named.boot //  // This is the boot file that /etc/init.d/inetsvc uses 
to run in.named //  //  // The "directory " statement points to where the 
name server (and // its files) will be running. // example: // directory  
/var/named //  //  //  // The "cache  .  named.ca" statement appears on all 
servers and tells the // server which servers are authoritative name servers 
for the root zone. // The addresses of the "higher authorities" are listed in 
the named.ca file. //  zone "." { type hint; file "named.ca"; };  //  
//  // forwarders 206.40.79.2 // 

RE: different result between normal query and zone transfer

[Darcy Kevin (FCA)]

The bottom line is that a *zone* is the basic administrative unit of 
AXFR/IXFR-based replication. If you create a new zone and you want a replica to 
serve it, you need to configure the replica to replicate it. There is no 
"automatic" mechanism within BIND to tell replicas to start slaving new zones. 
If you have a common provisioning/configuration-control mechanism, then this 
can be quite convenient, but it sounds like this is between you and your ISP, 
so I assume that no such common framework exists. You have to follow their 
procedures for getting the new zone transfer definition established, whether 
that be a phone call, an email, filling out an online form, something like that.


- Kevin



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of MAYER 
Hans
Sent: Sunday, July 09, 2017 1:14 AM
To: bind-users@lists.isc.org
Subject: Re: different result between normal query and zone transfer


Hi Steven, 

Many thanks for your answer. 
Isn’t there a flag or option to say handle all sub-zones like normal A or CNAME 
records too ? 

// Hans



> On 6 Jul 2017, at 15:05, Steven Carr  wrote:
> 
> On 6 July 2017 at 12:29, MAYER Hans  wrote:
>> For me this looks like a bug. Why is the answer for a normal query different 
>> than the answer from a zone transfer ?
>> Or do I miss a special flag for this setup ?
>> I am using BIND 9.11.1  but I had the same issue with older 
>> versions too.
> 
> A zone transfer is transferring the contents of the zone, the zone in 
> question is 'iiasa.ac.at', but you've also created a subzone 
> 'test44.iiasa.ac.at' which is a completely separate point of 
> administration that just happens to hide records inside of the parent 
> zone. So on your slaves you will also need to slave the subzone if you 
> want it to override the records there.
> 
> A query will traverse the tree until it finds the lowest point of 
> delegation with which to obtain a response from.

___
Please visit https://lists.isc.org/mailman/listinfo/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 w/ Forwarding Zone in Caching-Only Config

[Darcy Kevin (FCA)]

You have a trailing dot in the zone definition. It makes a difference.

Personally, I wouldn't use forwarding at all, and I'd build this for 
scalability. Define a master zone for, say, 168.136.dnssd.presto, and then 
delegate from that to whatever address ranges you deploy Presto to in the 
future (43.168.136.dnssd.presto today, maybe 99.168.136.dnssd.presto later). 
When I say "define a master zone", of course, I mean do that on one of the 
servers. The other one would then slave it.

Note that if you have global forwarding enabled, and if you're using any zone 
type other than "forward" (e.g. master, slave, stub), you'll need to disable 
the global forwarding for the part of the namespace you want to resolve 
internally, by putting "forwarders { };" in the relevant zone definition.

{RANT ON}

This Presto thing is a terrible product, from a DNS perspective, if (as appears 
from the admin guide at 
https://download.collobos.com/en/presto2/files/administrator_guide.pdf) there 
is no option to set the domain name for resolution of resource names. It seems 
dnssd.presto is hard-coded into the product, yet generally speaking, it's a bad 
practice to make TLDs up out of thin air and use them an IP network. A TLD that 
is "private" today (as .presto happens to be) can become "public" tomorrow, if 
ICANN decides to award a TLD assignment to, say, the Presto which makes kitchen 
appliances and gadgets (https://www.gopresto.com/), which is certainly *much* 
more well-known than the networking company, and thus has a stronger claim to 
the TLD. Suddenly, then, your devices could be confused between the internal 
and external versions of the TLD. This is a mistake *many* administrators 
regretted later. 

It is better to use a subdomain of one's *unique*, publically-registered domain 
name. But, apparently, this product doesn't allow that.

{RANT OFF}

- Kevin



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Michael 
W. Fleming
Sent: Tuesday, June 27, 2017 12:14 PM
To: bind-users@lists.isc.org
Subject: Problem w/ Forwarding Zone in Caching-Only Config

We're setting up a wireless printing service that uses 
Zeroconf/bonjour/rendevouz dns entries. The product, Presto, has it's own dns 
server for a private, on-campus only zone (presto.). We're running bind 9.9 
with a master server, three slaves and two caching-only servers (anycasted to 
136.168.255.2). We have the following in named.conf (as per the vendor) on the 
caching-only servers.

zone "presto." {
  type forward;
  forward only;
  forwarders { 136.168.2.66; };
};

I manually added some required dns entries in our zone (as per vendor),
e.g.:

dig +short ptr b._dns-sd._udp.0.43.168.136.in-addr.arpa
0.43.168.136.dnssd.presto.

However, when I query the presto address, the query is sent to the roots, not 
the presto server:

$ dig ptr 0.43.168.136.dnssd.presto.

; <<>> DiG 9.11.1 <<>> ptr 0.43.168.136.dnssd.presto.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46445 ;; flags: qr aa rd 
ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.43.168.136.dnssd.presto. IN  PTR

;; AUTHORITY SECTION:
.   86400   IN  SOA a.root-servers.net. 
nstld.verisign-grs.com. 2017062002
1800 900 604800 86400

;; Query time: 2 msec
;; SERVER: 136.168.255.2#53(136.168.255.2) ;; WHEN: Tue Jun 20 10:04:25 PDT 
2017 ;; MSG SIZE  rcvd: 129

I am by no means a bind wizard. Any help would be appreciated.

Many thanks.

--
Michael Fleming, IT Networking, Datacenter & Telecom, CSU, Bakersfield 
___
Please visit https://lists.isc.org/mailman/listinfo/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: Stop Reverse resolution query Logging

[Darcy Kevin (FCA)]

BIND has no way of differentiating these queries, since reverse-lookup queries 
aren't "special".

But certainly, if you syslog rather than writing directly to a file, there are 
syslog daemons that can filter, based on regex'es and the like.


- Kevin

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Job
Sent: Thursday, June 01, 2017 10:28 AM
To: bind-users@lists.isc.org
Subject: Stop Reverse resolution query Logging

Dear guys,

is there a way in Bind 9 to stop logging (to bind.log standard file) all the 
in-addr.arpa queries?
We would like to log everything else but not the reverse resolution queries.

Thank you!
F
___
Please visit https://lists.isc.org/mailman/listinfo/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: Ending a TXT record with a backslash?

[Darcy Kevin (FCA)]

In the grand tradition of _ceci_n'est_pas_une_pipe_, how dig *represents* a 
piece of TXT contents isn't necessarily how it *is*.

I just verified (via tcpdump) that a TXT record label that shows up as "blah\\" 
in dig's (and host's) output, actually only contains a single backslash (hex 
code 5C), on the wire. So, anything that uses a resolver-library routine to 
fetch this data, will only see a single backslash. If it's just a wrapper 
around "dig" or some other command-line utility, then it needs to know the 
idiosyncracies of whatever it's wrapping.

The reason that dig "over-escapes" stuff like this, in its representation, is 
so that folks can take dig output and paste it back into master files 
_verbatim_.

I'd be more concerned about the folks asking for this TXT record. Seems they're 
doing something proprietary, but not "sub-classing" their use with, say, an 
application-specific prefix, and, say, a colon delimiter. If the "foo" app 
wanted a "path=" variable in a TXT record, maybe it could be encoded as 
"foo:path=xxx", so that it would never collide with the "bar" app that later 
wants to also encode a "path=" variable, at the same point in the namespace 
hierarchy, for a different, incompatible purpose.

This is part of the inherent problem with using DNS TXT records to store 
arbitrary app data. But, you most likely already know this, since the 
Experimental RFC you referenced (1464) discussed it briefly in Section 4.



- Kevin


From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
MURTARI, JOHN
Sent: Tuesday, May 30, 2017 3:04 PM
To: bind-users@lists.isc.org
Subject: Ending a TXT record with a backslash?

Folks,
Recently had an issue with someone who wanted this for a TXT 
record:

murt2 IN TXT  "path=\";

Now, not sure wny they wanted it - maybe the root directory in 
Windows???  But anyway,  BIND does not like it.

zone example.com/IN: loading from master file db.example.com failed: unbalanced 
quotes

Of course, we could escape the backslash.  Which BIND then 
likes and the zone will load.  But a dig gives you:

;; ANSWER SECTION:
murt2.example.com.  83000   IN  TXT "path=\\"

Which isn't really the same thing?  Took a look at RFC1464 
(Using DNS to Store Arbitrary String Attributes),  
https://tools.ietf.org/html/rfc1464,   read this:

   All printable ASCII characters are permitted in the attribute value.
   No characters need to be quoted with a "`".  In other words, the
   first unquoted equals sign in the TXT record is the name/value
   delimiter.  All subsequent characters are part of the value.

   Once again, note that in most implementations the backslash character
   is an active quoting character (and must, itself, be quoted).

That last sentence really has me stuck!  Too many adjectives?  
Are there 'inactive' quoting characters?

The RFC did have an example, but I couldn't work it out...

   AttributeAttribute   Internal Form   External Form
   Name Value   (server to resolver)(TXT record)
   =\=  `==\=   "`==\\="

Any suggestions are welcome & please excuse my attempts at 
humor above.
Best regards!
John


John Murtari - jm5...@att.com
Ciberspring
office: 315-944-0998
cell: 315-430-2702

___
Please visit https://lists.isc.org/mailman/listinfo/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: Weird issue with bind & router

[Darcy Kevin (FCA)]

As far as I know, the only "special" thing that BIND does consistently on a 
restart, that it doesn't do on a regular basis in normal operation, is a 
"priming" query to whatever is configured as root nameservers. I suppose it's 
_possible_ that there is something about priming queries, particularly, that 
exercises a codepath in the router, with a horrible bug in it. This is - as 
Mark speculated - much more likely if the router is trying to do something 
"smart" with your DNS, e.g. intrusion detection/prevention, reputation-based 
blacklisting, something like that. I'd look at the router config and see if you 
can turn any feature(s) like that *off*.

Failing that, if priming queries are the culprit, it should be fairly easy to 
reproduce the scenario, since one can issue identical-looking queries to the 
same root-nameserver destinations (the main difference between these and other 
command-line-generated queries would consist of making them non-recursive). If 
you can reproduce the issue at will, maybe the router manufacturer would 
actually listen to your trouble report.

Putting on my InfoSec paranoia hat for a second, if it's the *responses* to the 
priming queries that are causing the router to go belly-up, then this is a 
scary prospect indeed, since it raises the possibility that evildoers could 
send *spoofed* responses like that, to routers of that make/model, and this 
would be a powerful Denial of Service attack.




- Kevin



From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chris 
Serella
Sent: Thursday, May 25, 2017 10:24 AM
To: bind-users@lists.isc.org
Subject: Weird issue with bind & router


I run a small dev system on my home network, housing dns etc all under the one 
server.

System: ubuntu16.04 server, ispconfig etc etc etc, you get the idea.

Anyway, the problem i am having comes down to the router rebooting (is it 
crashing? I cant tell) every time bind starts/restarts. This ordinarily wouldnt 
be an issue, DNS rarely changes so the service does not need restarting but the 
problem occurs on system boot too.

The router in question is a Plusnet Hub One which I believe is actually a 
repackaged BT Hub 5. The "server" is an ACER AX3300 desktop with ubuntu server 
installed.

Troubleshooting was difficult as i couldnt isolate what it was until i went 
over to ISPConfig for assistance, they informed me that a DNS reload on their 
software simply saves data to files and initiates a service restart.

With this information to hand I made no changes to the DNS in ISPConfig, 
instead i opened a terminal and tunnels into the server and issued a bind9 
restart from there.

Sure enough the problem reared its ugly little head, The ssh session dropped 
out and looking over to the router i could see it was going through its power 
cycle. To be sure this wasn't some freakishly well timed coincidence, I 
completed the steps several times more (3) all with the same result.
___
Please visit https://lists.isc.org/mailman/listinfo/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 forwarding

[Darcy Kevin (FCA)]

As others have commented, more information about your config and your setup 
need to be provided, before a proper troubleshooting can occur. I would add, 
you should be more specific than just “resolution error”. Is it a timeout? An 
NXDOMAIN? A SERVFAIL? A so-called “NODATA” response or a referral (i.e. 
NOERROR, but 0 answers)? You might need to use a tool like “dig” to see for 
sure what the response is (nslookup often triggers domain-suffixing behavior, 
which obfuscates the actual error, so I would stay away from nslookup as a DNS 
troubleshooting tool). Another important piece of information about the 
response is the status of the flags, e.g. whether the RA (Recursion Available) 
and/or AA (Authoritative Answer) flags are set.

What I would say, generally, is that if you want your new setup to look as 
close as possible to your old setup, then your new server should be 
authoritative for the same zones as your old server is/was. Thus, I would lean 
in the direction of making the new server slave for those zones. That will give 
you a better “apples-to-apples” comparison, than trying to mix-and-match 
authoritative and forwarding behavior, which can greatly complicate things.




- Kevin


From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Elias 
Pereira
Sent: Wednesday, May 17, 2017 4:44 PM
To: bind-users@lists.isc.org
Subject: DNS forwarding

Hello,

Our scenario today consists of one:

- DNS Server (Authoritative to our subdomains. Ex: 
www.mydomain.com*, 
moodle.mydomain.com, etc)
- samba3 PDC server
- Openldap server (user base for samba)

All our IPs are public.

This scenario above works like a charm!! :D

Now, I'm implementing a new samba4 AD server.

In order for me to be able to put users in the AD domain, I need to configure 
the samba4 AD IP as primary dns on the computers. In the bind installed on 
samba4 AD I configured the "forwarder" variable with the IP of our DNS server.

The problem is that from this computer, if I need to access an internal 
subdomain, for example our webserver*, I can not access. Gives resolution 
error. For any other site, for example, google.com, I can 
access.

I'm not finding the problem. Any idea?

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

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

RE: BIND 9 windows XP builds

[Darcy Kevin (FCA)]

I guess I'm not so worried about a non-Internet-connected Windows XP box 
forwarding to an Internet-connected box that's running a modern (preferably 
non-Windows) OS. Assuming that the BIND versions are patched up to date, of 
course.

To be sure, all things must come to end, and XP support for BIND is no 
exception. But, the risk calculation runs something like: is there still enough 
critical mass of BIND-on-XP out there that there is a *bigger* risk incurred by 
no longer incorporating new security updates, or, has the population dwindled 
to the point where *only* the withdrawal of support will get the remainder to 
upgrade/replace/refresh their XP boxes?


- Kevin



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Paul 
Kosinski
Sent: Tuesday, April 18, 2017 5:09 PM
To: bind-users@lists.isc.org
Subject: Re: BIND 9 windows XP builds

Yes, I suppose not every machine running BIND is connected to the Internet. But 
how many are network inaccessible to every machine that
*is* connected to the Internet and might be compromised?

We run a local BIND for our LAN to avoid HOSTS files, but that same machine is 
connected to the Internet -- and runs a different instance of BIND to be 
authoritative for our domain. (No, not a separate machine, it's a very small 
installation.)

So, how many BINDs are completely isolated from the Internet, even under 
transitive closure of the internal network? It's surely a proper subset of all 
instances of BIND, but I doubt if it's other than a quite small subset.


On Tue, 18 Apr 2017 17:22:24 +
"Darcy Kevin (FCA)" <kevin.da...@fcagroup.com> wrote:

> Unspoken and false assumption: that every machine running BIND is 
> connected to the Internet.
> 
> I'm no fan of old, broken Microsoft OSes (or even the newer ones, for 
> that matter), but let's be clear here: BIND is for anyone who doesn't 
> want to maintain a "hosts" file. "Connected to the Internet" is a much 
> smaller subset of *that* set.
> 
>   - Kevin
> 
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf 
> Of Paul Kosinski Sent: Monday, April 17, 2017 9:08 PM
> To: bind-users@lists.isc.org
> Subject: Re: BIND 9 windows XP builds
> 
> I can see somebody running XP for some "legacy" software that doesn't 
> run nicely on newer versions of Windows, but I would think it 
> extremely risky to have such a machine connected to the Internet.
> 
> Maybe whoever runs BIND on XP should consider converting that machine 
> to Linux, and running BIND on Linux?
> 
> 
> On Mon, 17 Apr 2017 20:30:43 +
> Evan Hunt <e...@isc.org> wrote:
> 
> > Greetings,
> > 
> > For some time ISC has been providing three Windows builds for each 
> > release of BIND 9: x64, win32, and windows XP.
> > 
> > Windows XP is well past its end of life and is no longer receiving 
> > security updates.  I'd like to stop supporting it after the upcoming 
> > maintenance release, but it's been pointed out to me that a 
> > significant number of people -- many thousands -- are downloading 
> > the XP version every time we put out a new release.
> > 
> > This information surprised me. If you're one of those people, would 
> > you mind responding, either on or off the list, to discuss it?  Why 
> > are you using XP to run a name server?  Is it possible you're still 
> > using the XP build out of inertia, but your OS would work equally 
> > well with the win32 build?  If you're really still running XP, do 
> > you have a plan for transitioning to something newer?
> > 
> > We want to support the needs of our users, but to do that we have to 
> > understand those needs, so please let us know what yours are.
> > Thanks,
> > 
> > --
> > Evan Hunt -- e...@isc.org
> > Internet Systems Consortium, Inc.

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

[Darcy Kevin (FCA)]

Unspoken and false assumption: that every machine running BIND is connected to 
the Internet.

I'm no fan of old, broken Microsoft OSes (or even the newer ones, for that 
matter), but let's be clear here: BIND is for anyone who doesn't want to 
maintain a "hosts" file. "Connected to the Internet" is a much smaller subset 
of *that* set.

- Kevin

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Paul 
Kosinski
Sent: Monday, April 17, 2017 9:08 PM
To: bind-users@lists.isc.org
Subject: Re: BIND 9 windows XP builds

I can see somebody running XP for some "legacy" software that doesn't run 
nicely on newer versions of Windows, but I would think it extremely risky to 
have such a machine connected to the Internet.

Maybe whoever runs BIND on XP should consider converting that machine to Linux, 
and running BIND on Linux?


On Mon, 17 Apr 2017 20:30:43 +
Evan Hunt  wrote:

> Greetings,
> 
> For some time ISC has been providing three Windows builds for each 
> release of BIND 9: x64, win32, and windows XP.
> 
> Windows XP is well past its end of life and is no longer receiving 
> security updates.  I'd like to stop supporting it after the upcoming 
> maintenance release, but it's been pointed out to me that a 
> significant number of people -- many thousands -- are downloading the 
> XP version every time we put out a new release.
> 
> This information surprised me. If you're one of those people, would 
> you mind responding, either on or off the list, to discuss it?  Why 
> are you using XP to run a name server?  Is it possible you're still 
> using the XP build out of inertia, but your OS would work equally well 
> with the win32 build?  If you're really still running XP, do you have 
> a plan for transitioning to something newer?
> 
> We want to support the needs of our users, but to do that we have to 
> understand those needs, so please let us know what yours are.  Thanks,
> 
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
> unsubscribe from this list
>
___
Please visit https://lists.isc.org/mailman/listinfo/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: Clean up dynamic names

[Darcy Kevin (FCA)]

Honestly, this is like asking for a closet that automatically throws out the 
items you pitch into it, once the items are deemed obsolete or junk.

The DNS database is a repository of information, like a closet, but it has no 
inherent way of knowing the value or currency of the information that is put 
into it. Therefore any "auto-cleaning" mechanism is going to be unreliable, at 
best.

Now, if you want, you can add "metadata" alongside your regular data, or in a 
parallel database, e.g. a timestamp or something like that. You could then use 
that "metadata" to make decisions on what to delete. Various layers on top of 
DNS itself can perform "aging" and "scavenging" in this way (Microsoft's 
solution does this). But that's not perfect either -- we've had major 
infrastructure outages due to erroneous scavenging of Microsoft-hosted DNS data.

The bottom line is that the processes which read and write data into/out of the 
DNS database are responsible for keeping track of it, evaluating it, and 
getting rid of data that is no longer needed or wanted. This is not something 
the database itself can do.


- Kevin



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Cuttler, Brian R (HEALTH)
Sent: Wednesday, February 08, 2017 11:59 AM
To: Users of ISC DHCP; bind-users@lists.isc.org
Subject: Clean up dynamic names

Hello Bind and DHCP users,

Sorry for the post to both lists, but it is a dynamic DNS question and I'm not 
sure where the answer will come from.

We replaced the network card in a printer, which had been working, we had a 
DHCP lease, we had created from DHCP a dynamic DNS forward and reverse record 
for the printer.

The new network card was configured to provide the same HOSTNAME information as 
the old card, we do this because the printers now carry network names that 
reflect their inventory tags.

I need the cleanest/best way to remove the old DNS records so that the DHCP 
server will be able to register the IP information in DNS.

Needless to say the TXT fingerprint information for the two network cards is 
different, so automatic cleanup, which would say, allow us to rename the 
printer if needing the same network card, will not work.

I suspect that # nsupdate removing the A, TXT and PTR records is the way to go, 
but hope for a quicker, less error prone method.

Thanks in advance,
Brian



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

[Darcy Kevin (FCA)]

I think the ISP may have done something untoward with 
87.233.202.162.in-addr.arpa, since I'm getting a NODATA response for that name, 
from the 233.202.162.in-addr.arpa zone, most probably because it's an empty 
non-terminal. But what would be under that, and why?


- Kevin


-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark 
Andrews
Sent: Friday, January 20, 2017 3:55 PM
To: bind-us...@isc.org
Subject: Re: rDNS


You have the netblock 162.202.233.80-162.202.233.87 (162.202.233.80/29).

When software performs a reverse lookup it constructs a DNS name from the 
address like 80.233.202.162.in-addr.arpa.  Now as the netblock is not a full 
/24 you either have to create 8 zones, one for each PTR record, or provide 
records at those names which map the lookups to new names.  The later is what 
has been done here.
The technique is described in RFC 2317.

ATT has delegated a zone for the first address in the address block to you.  
That zone is called 80.233.202.162.in-addr.arpa.  It has then added CNAME 
records to map lookups for the rest of the address in your address block into 
this zone.

e.g.

81.233.202.162.in-addr.arpa. CNAME 81.80.233.202.162.in-addr.arpa.
...
86.233.202.162.in-addr.arpa. CNAME 86.80.233.202.162.in-addr.arpa.

The 80.233.202.162.in-addr.arpa zone should look like this.

$TTL 1h
@   SOA ns1.archaxis.net. me.archaxis.net. (
2017012002 ; Serial
1h ; Refresh
1h ; Retry
4w ; Expire
1h ) ; Negative cashing TTL
NS ns1.archaxis.net.
NS ns2.archaxis.net.
PTR network.archaxis.net.
81  PTR alpha.archaxis.net.
82  PTR bravo.archaxis.net.
87  PTR broadcast.archaxis.net.

I increased the expire field to 4 weeks as it was way too small.
Note the reverse for 162.202.233.80 is NOT mapped to a new name so the PTR 
record for that address is at the zone's apex.  As all the records had a TTL of 
1 hour I set the default TTL to that value and removed the per record setting 
of the TTL.  I also removed the class field as that is inherited from the 
zone's declaration.

Don't forget to bump the zones serial when you install it.

Once you have the above sorted out and have tested it.  You now need to slave 
the zone 233.202.162.in-addr.arpa as that contains the CNAME records.  ATT 
should allow you to transfer it.  If they don't find a ISP that knows what they 
are doing.  You need a local copy of the zone so that when you link goes down 
you can still do reverse lookups.

zone "233.202.162.in-addr.arpa" {
type slave;
masters { 151.164.1.1; };
file "233.202.162.in-addr.arpa";
};

Mark

In message <20170120162146.ga14...@fantomas.sk>, Matus UHLAR - fantomas writes:
> On 20.01.17 09:57, Ron Wingfield wrote:
> >   I am having difficulty configuring reverse DNS. This has been a
> problem
> >   for over a year between my server(s) and my ISP, AT Specifically, I
> >   cannot eMail to any recipient that requires rDNS verification, e.g.,
> >   SBCglobal.net, Comcast.net, or AOL. Very frustrating.
>
> >   . . .why shouldnt this point to my server, 162.202.233.81 and not
> >   AT?
>
> because reverse domains are also tracked from the DNS root:
>
> 233.202.162.in-addr.arpa. 7200IN  SOA ns1.swbell.net.
> postmaster.swbell.net. 2016061700 10800 900 604800 3600
>
> 81.233.202.162.in-addr.arpa.  7200IN  CNAME   
> 81.80.233.202.162.in-addr.arpa.
>
> >   I have coded my BIND 9 in-addr.arpa zone file as follows:
> >
> >   $ORIGIN 233.202.162.in-addr.arpa.
>
> stop defining $ORIGIN in zone file. the $ORIGIN is taken from named "zone"
> statement.
>
> According to those above you have to configure zone 
> 80.233.202.162.in-addr.arpa.
> and adk swbell.net to fetchit from you.
>
> >   $TTL 3h
> >   @ IN SOA ns1.archaxis.net. me.archaxis.net. (
> >2017012002 ; Serial
> >1h ; Refresh
> >1h ; Retry
> >1h ; Expire
> >1h ) ; Negative cashing TTL
> >
> >3600 IN NS ns1.archaxis.net.
> >3600 IN NS ns2.archaxis.net.
> >
> >   80 3600 IN PTR network.archaxis.net.
> >   81 3600 IN PTR alpha.archaxis.net.
> >   82 3600 IN PTR bravo.archaxis.net.
> >   87 3600 IN PTR broadcast.archaxis.net.
> >
> >   What is wrong? Is this my problem, or with AT?
>
>
>
> --
> 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.
> Spam is for losers who can't get business any other way.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, 

RE: Restricted bind to my domain only

[Darcy Kevin (FCA)]

Seems like your requirements call for the classic, old-school "internal root" 
setup. Define your own root zone that *only* has delegations for example.com 
and whatever parts of the in-addr.arpa namespace you want to resolve. That way, 
everything outside the example.com namespace and the in-addr.arpa namespace(s) 
will get an NXDOMAIN response.

After doing that, you may find that you don't even need the "type forward" 
definition for example.com. If you happen to run across a subzone that isn't 
delegated properly, you can probably work around that "broken" subzone with a 
"stub" zone definition, until it can be fixed. Forwarding is usually to be 
considered as a last resort, if you really *cannot* talk directly to any of the 
authoritative nameservers for a given zone (e.g. in a DMZ scenario).


- Kevin


-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Luis 
Felipe Dominguez Vega
Sent: Monday, January 16, 2017 10:17 AM
To: bind-users@lists.isc.org
Subject: Restricted bind to my domain only

Hello, i was searching into google to find my problem, but i think that is 
better write to the list. I am using Bind with Samba 4 (with BIND_DLZ) serving 
the domain mtz.example.com, but i need resolv throw another server the querys 
to domain example.com and anothers subdomains (like grm.example.com, 
vcl.example.com), but i dont want resolve any other (to prevent DNS Tunnel). 
So i need enable the recursion and permit to my network that recursion, the 
problem is that always resolve the google.com, facebook.com, etc... and i want 
only resolve the names into Samba (BIND_DLZ) and all others be forwarded by my 
another server, files.

Note: 192.168.44.2 is my forward DNS server that only accept example.com 
domains and subdomains

named.conf:
===
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.default-zones";
include "/var/lib/samba/private/named.conf";
===

named.conf.options:
===
options {
directory "/var/cache/bind";
dump-file "/var/cache/bind/data/cache_dump.db";
statistics-file "/var/cache/bind/data/named_stats.txt";

dnssec-validation auto;

auth-nxdomain no;# conform to RFC1035
datasize default;
empty-zones-enable no;
tkey-gssapi-keytab "/var/lib/samba/private/dns.keytab";

#recursion no;

allow-query { 192.168.0.0/24; 10.11.0.0/24; 127.0.0.1/8; };
allow-recursion { 127.0.0.1/8; 192.168.0.0/24; 10.11.0.1/24; };
allow-update{ 127.0.0.1; };
   allow-transfer  { 192.168.0.0/24; };

version none;
hostname none;
server-id none;

listen-on-v6 { none; };
};

logging {
channel xfer-log {
file "/var/log/named.log";
print-category yes;
print-severity yes;
severity info;
};

category xfer-in{ xfer-log; };
category xfer-out   { xfer-log; };
category notify { xfer-log; };
};

statistics-channels {
inet 127.0.0.1 port 8653 allow { 127.0.0.1; }; }; 
===

named.conf.default-zones
===
// prime the server with knowledge of the root servers #zone "." { #  type 
hint; #  file "/etc/bind/db.empty"; #}; #zone "." {
#type forward;
#forward only;
#forwarders { 192.168.44.2; };
#};

// be authoritative for the localhost forward and reverse zones, and for // 
broadcast zones as per RFC 1912

zone "example.com" {
type forward;
forward only;
forwarders { 192.168.44.2; };
};

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";
};
===
___
Please visit https://lists.isc.org/mailman/listinfo/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: False positive on inscure zone update by IP?

[Darcy Kevin (FCA)]

Well, I suppose it's a little silly that the informational message would count 
"none" as an "IP address", but on the other hand, why specify "allow-update { 
none; };" when that's the default? It probably never occurred to the 
creator/author of the informational message that someone would "superfluously" 
define an allow-update that exactly mirrors the default behavior.

If you're doing that only for documentation purposes, you could use a comment 
instead.


- Kevin

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Michael 
Weiser
Sent: Friday, November 18, 2016 12:32 PM
To: bind-users@lists.isc.org
Subject: False positive on inscure zone update by IP?

Hi,

today I noticed the following log messages from my caching-only bind on
startup:

zone 'localhost' allows updates by IP address, which is insecure zone 
'version.bind' allows updates by IP address, which is insecure zone 
'hostname.bind' allows updates by IP address, which is insecure zone 
'authors.bind' allows updates by IP address, which is insecure zone 'id.server' 
allows updates by IP address, which is insecure

What's bugging me about those it that I have set allow-updates { none; } in the 
global options section of my named.conf. Setting it on the localhost zone 
explicitly doesn't change anything.

I've looked at the implementation of dns_acl_isinsecure() and got the 
impression that there might simply be a check missing for special ACL "none".

So I wonder: Can I ignore these messages?
--
Thanks,
Michael
___
Please visit https://lists.isc.org/mailman/listinfo/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 DNS Architecture - AD and BIND

[Darcy Kevin (FCA)]

Same here. Slave the AD zones, all end-user machines use BIND-based (Infoblox) 
servers for resolution, on Anycast addresses. DHCP servers (also Infoblox) 
update DNS for the clients, with the client names being registered in non-AD 
zones (some of which are defined by geography, with a generic "catch-all" for 
clients not designated as belonging to one of those geo-defined zones).

If we *really* wanted to maintain client names in AD zones, Infoblox has an 
add-on product that would allow us to manage everything "from a single pane of 
glass", as the marketing folks say. But we haven't come up with a really 
compelling business case for registering them in AD zones, yet. Registering 
them where they are currently, works fine for us, given how our Suffix Search 
Lists, etc. are set. Microsoft subtly deprecates this setup by referring to it 
as a "disjoint namespace" in their documentation (PHBs don't like to hear 
architectures being described as "disjoint"), but it is fully supported by 
Microsoft at the infrastructure level (apps which make stupid assumptions might 
be a different story), so don't let their terminology scare you.


- Kevin


-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Barry 
S. Finkel
Sent: Friday, November 18, 2016 10:29 AM
To: bind-users@lists.isc.org
Subject: Re: Enterprise DNS Architecture - AD and BIND


On Tue, 8 Nov 2016 16:09:36 -0800 Ray Van Dolson 
wrote:

> Greetings;
>
> Am reviewing our DNS setup which has organically evolved over the 
> years and most certainly is due for an update:
>
> - We have AD servers responsible for our primary domain (internally).
>
> - We have other sets of AD servers responsible for other domains in
>   DMZ's and such.
>
> - We have a BIND Master/Slave pair acting as a hidden master for
>   external zones as well as doing split view for some of those same
>   zones where we want to return "non-public" IP's for queries that
>   would otherwise be answered with an external address.
>
> - We have multiple BIND caching servers.  Some at remote sites that
>   handle split duty for Internet resolution (enabling accurate
>   geolocation for Internet based services -- our own included) and
>   internal lookups.
>
>   In some cases, these "remote" caching servers need to forward lookups
>   to other "super" caching servers which have more privileged access to
>   the authoritative servers listed above... there are about a dozen of
>   these zones.
>
>   They do static-stub zones for the AD managed zones.
>
>   Another challenge is when clients point to them directly, Dynamic DNS
>   (RFC2136) doesn't work.  Theoretically we could make BIND handle this
>   and forward on to AD, but adds complexity.
>
>   The caching servers also do RPZ.
>
> We're now wanting to add some additional logic to resopnd differently 
> to VPN clients for some of our VoIP technologies to send RTP over the 
> Internet vs. over a VPN tunnel...
>
> I'd like to make this all much simpler, avoid mixing roles of servers 
> and help guide us as we decide what servers to deploy where.  KISS 
> principle I guess.
>
> In an ideal world, I could completely pitch the whole split view thing 
> (where rr.domain.com resolves differently for Internet clients than 
> for "internal" clients).  I can't think of a good way to avoid this 
> complexity, however.
>
> What I'm thinking:
>
> - Have an AD server at every location we have a BIND server.  This way
>   client machines talk DNS *only* to AD servers so Dynamic DNS &
>   friends work reliably.  AD servers would then forward to BIND servers
>   as needed.
>
> + Alternative: Configure clients to do DNS updates via DHCP Option
>   81, etc. instead of via Dynamic DNS.  This would allow clients to
>   point at BIND and take advantage of Anycast for resiliency and I
>   avoid needing to figure out how to make BIND pass RFC 2136
>   requests on from clients to AD reliably...
>
> - Caching Servers will be the same configuration no matter where they
>   are, and do the same things:
>
> + "." will forward out to OpenDNS or Google, etc. for Internet
>   lookups.
>
> + Will be a "slave" for all AD owned domains.  Thought here is
>   better client response times and fewer issues w/ TTL and cache
>   and better resiliency...
>
> - Alternative: Leave these as static-stub, but now I made need
>   logic in Ansible or whereever to point to "nearby" AD servers
>   depending on where the BIND server lives to keep response
>   times low when things aren't cached.  That or not care about
>   latency...
>
> + Will be a "slave" for all of the split-view zones (only for the
>   "internal" view).  Could do static-stub here as well, but think
>   slave may serve us better for similar 

RE: Wildcard SRV record?

[Darcy Kevin (FCA)]

Correct, wildcards don't work that way; in fact, it would be more accurate to 
say that _vlmcs._tcp.*.foo. isn't a wildcard at all (it's just a DNS name that 
happens to have an asterisk as one of its labels). See RFC 4592.

- Kevin

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Stephen 
Pape
Sent: Monday, October 31, 2016 12:36 PM
To: bind-users@lists.isc.org
Subject: Wildcard SRV record?

Hello all,

I have bind configured with a single TLD (.foo), and inside that are records 
for a large number of subdomains (machine1.a.foo, machine2.a.foo, 
machine1.b.foo, machine2.b.foo, etc.). DHCP clients are assigned a domain based 
on some factors, but it might be a.foo, b.foo, c.foo, etc.

I'm trying to add a SRV record for everyone under .foo. I've tried:

_vlmcs._tcp.*.foo.IN  SRV 0 0 1688 ais-dc01.ainfosec.com.

... but it seems that wildcards don't work that way. I've tried something 
similar with CNAMEs, but that didn't work either.

What DOES work is adding a CNAME record for each and every domain that I need. 
So a CNAME for _vlmcs._tcp.a.foo, _vlmcs._tcp.b.foo, etc.

Is there a better way for me to do this, or do I have to generate a whole lot 
of specific CNAME records?

Thanks!

-Stephen
___
Please visit https://lists.isc.org/mailman/listinfo/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: merging reverse zone data obtained from two different masters

[Darcy Kevin (FCA)]

Ideally, whatever frontend you use to maintain the "forward" records for these 
zones, should be smart enough to, in parallel, populate the corresponding 
entries in the common reverse zone.

But, failing that, it shouldn't be that hard to write a script that 
periodically pulls zone transfers of the forward zones and merges that data to 
create/update the common reverse zone. If the ranges used by these Zone1/Zone2 
hosts overlap, you'll have to decide how to handle collisions, of course.


- Kevin


-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of blrmaani
Sent: Sunday, October 23, 2016 5:56 PM
To: comp-protocols-dns-b...@isc.org
Subject: merging reverse zone data obtained from two different masters

We have hosts in two different zones but use same subnet. Zone1 is generated by 
Master1 and Zone2 is generated by Master2.

Slave1 runs BIND and would like to merge the reverses generated on Master1 and 
Master2. How do I do this?

thanks
Blr
___
Please visit https://lists.isc.org/mailman/listinfo/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: defines ip to acl

[Darcy Kevin (FCA)]

And don't forget the copious comments in named.conf, so that your successor can 
easily see, at a glance, what start/end addresses those clusters of ACL 
elements represent.


- Kevin


-Original Message-
From: Darcy Kevin (FCA) 
Sent: Monday, October 17, 2016 3:11 PM
To: bind-users@lists.isc.org
Subject: RE: defines ip to acl

Well, things are messy, because you haven't carved up your subnet on 
bit-boundaries. BIND ACLs are either individual IPs, CIDR blocks, negations, or 
some combination of these. It can be done:

192.168.1.1 through 192.168.1.99 = !192.168.1.0; 192.168.1.0/26; 
192.168.1.64/27; 192.168.1.96/30;

192.168.1.100 through 192.168.1.199 = 192.168.1.100/30; 192.168.1.104/29; 
192.168.1.112/28; 192.168.1.128/26; 192.168.1.192/29;

I might have made an error in the above -- did I mention that this is very 
error-prone as well? :-)


- Kevin

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Pol 
Hallen
Sent: Monday, October 17, 2016 2:37 PM
To: bind-users@lists.isc.org
Subject: defines ip to acl

Hello all :-)

I need to setup 2 kind of acl on same network, ie:

ip from 192.168.1.1 to 192.168.1.99 belongs to acl1 and ip from 192.168.1.100 
to 192.168.1.199 to acl2

acl net1 { 192.168.1.1-99/24 };
acl net1 { 192.168.1.99-199/24 };

what's the correct way? I didn't find nothing :-/

thanks for help

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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/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: defines ip to acl

[Darcy Kevin (FCA)]

Well, things are messy, because you haven't carved up your subnet on 
bit-boundaries. BIND ACLs are either individual IPs, CIDR blocks, negations, or 
some combination of these. It can be done:

192.168.1.1 through 192.168.1.99 = !192.168.1.0; 192.168.1.0/26; 
192.168.1.64/27; 192.168.1.96/30;

192.168.1.100 through 192.168.1.199 = 192.168.1.100/30; 192.168.1.104/29; 
192.168.1.112/28; 192.168.1.128/26; 192.168.1.192/29;

I might have made an error in the above -- did I mention that this is very 
error-prone as well? :-)


- Kevin

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Pol 
Hallen
Sent: Monday, October 17, 2016 2:37 PM
To: bind-users@lists.isc.org
Subject: defines ip to acl

Hello all :-)

I need to setup 2 kind of acl on same network, ie:

ip from 192.168.1.1 to 192.168.1.99 belongs to acl1 and ip from 192.168.1.100 
to 192.168.1.199 to acl2

acl net1 { 192.168.1.1-99/24 };
acl net1 { 192.168.1.99-199/24 };

what's the correct way? I didn't find nothing :-/

thanks for help

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

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

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

RE: update failed: not authoritative for update zone (NOTAUTH)

[Darcy Kevin (FCA)]

To be clear, the zone is defined in named.conf -- otherwise the original poster 
would have never said that "allow-update" was configured for the zone -- but 
there is something wrong with the configuration, or in the zone file itself, 
that is preventing it from being properly loaded and served.

You (original poster) should probably look at the logs from the last named 
startup to see if there were any problems parsing the config, or loading the 
zone file.

Another possibility, if you're running views, is that your dynamic update is 
matching the wrong view, in which the zone is defined differently, or possibly 
not at all.


- Kevin



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark 
Andrews
Sent: Thursday, October 13, 2016 4:00 PM
To: rams
Cc: bind-users
Subject: Re: update failed: not authoritative for update zone (NOTAUTH)


In message 
, rams writes:
> Hi,
> Greetings !!!
> I am getting the following error when we do updates to bind even we 
> have configured allow-update ANY, named folder is having all 
> permissions and also owner ship.
> 
> updating zone 'xtldprimary.com/IN': update failed: not authoritative 
> for update zone (NOTAUTH)
> 
> 
> Kindly some one help me to resolve this issue.

Read the error message.  Named is not authorative (configured) for the the zone 
to be updated.

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

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

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

RE: Unspecified error DNS query

[Darcy Kevin (FCA)]

There's nothing particularly unusual about the "retrying in TCP mode" message - 
as Mark explained, that happens whenever the packet size is big and EDNS0 is 
not being used.

I looked up this name from an internal Windows 7 box through a BIND-based 
forwarder (in North America), and it resolves fine:

Non-authoritative answer:
Name:live-namnorth.office365.com
Addresses:  40.97.169.162
  132.245.46.34
  132.245.22.146
  132.245.37.130
  40.96.7.114
  132.245.250.130
  132.245.71.178
  132.245.75.18
  132.245.59.114
  40.97.144.50
Aliases:  outlook.live.com
  edge-live.outlook.office.com
  outlook-live-com.a-0010.a-msedge.net
  ipv4.outlook.com
  outlook.live.com.glbdns2.microsoft.com


C:\Windows\System32>

Like your response, there are 5 CNAMEs and 10 A records.

So, I would say either something is wrong with your client build, or there's a 
middlebox somewhere that's messing with the packets, possibly because it 
doesn't how the TCP flavor of DNS works. Time to take a packet capture and see 
what's really going on.




- Kevin


From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Daniel 
Dawalibi
Sent: Friday, October 07, 2016 8:01 AM
To: bind-users@lists.isc.org
Subject: Unspecified error DNS query

Hello


We are getting "Unspecified error" when querying our DNS server (Query: 
outlook.live.com)  from  a PC communication with our DNS
We tried to perform the same query from the DNS itself (local host) and we 
found that the Dig output is showing with the following message "Truncated, 
retrying in TCP mode".
We also observed that the message size of the requested query 
"outlook.live.com" increased recently from MSG SIZE 221 to 770
Can you please help why we are getting this error (client side) and why the TCP 
mode is shown in the dig output since other queries do not show TCP mode in 
their output?

[root@DNS1 dan]# dig outlook.live.com
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> outlook.live.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45725
;; flags: qr rd ra; QUERY: 1, ANSWER: 15, AUTHORITY: 7, ADDITIONAL: 11

;; QUESTION SECTION:
;outlook.live.com.  IN  A

;; ANSWER SECTION:
outlook.live.com.   881 IN  CNAME   edge-live.outlook.office.com.
edge-live.outlook.office.com. 280 INCNAME   
outlook-live-com.a-0010.a-msedge.net.
outlook-live-com.a-0010.a-msedge.net. 160 IN CNAME ipv4.outlook.com.
ipv4.outlook.com.   126 IN  CNAME   
outlook.live.com.glbdns2.microsoft.com.
outlook.live.com.glbdns2.microsoft.com. 280 IN CNAME 
live-emeaeast3.office365.com.
live-emeaeast3.office365.com. 294 INA   40.101.44.178
live-emeaeast3.office365.com. 294 INA   134.170.68.82
live-emeaeast3.office365.com. 294 INA   40.101.28.178
live-emeaeast3.office365.com. 294 INA   40.101.1.82
live-emeaeast3.office365.com. 294 INA   132.245.79.242
live-emeaeast3.office365.com. 294 INA   40.96.21.34
live-emeaeast3.office365.com. 294 INA   40.101.9.2
live-emeaeast3.office365.com. 294 INA   40.101.60.2
live-emeaeast3.office365.com. 294 INA   40.96.21.50
live-emeaeast3.office365.com. 294 INA   132.245.194.242

;; AUTHORITY SECTION:
office365.com.  170080  IN  NS  ns2.msft.net.
office365.com.  170080  IN  NS  ns1a.o365filtering.com.
office365.com.  170080  IN  NS  ns3.msft.net.
office365.com.  170080  IN  NS  ns1.msft.net.
office365.com.  170080  IN  NS  ns4a.o365filtering.com.
office365.com.  170080  IN  NS  ns4.msft.net.
office365.com.  170080  IN  NS  ns2a.o365filtering.com.

;; ADDITIONAL SECTION:
ns1.msft.net.   289 IN  A   208.84.0.53
ns2.msft.net.   170080  IN  A   208.84.2.53
ns3.msft.net.   289 IN  A   193.221.113.53
ns4.msft.net.   170080  IN  A   208.76.45.53
ns1a.o365filtering.com. 311 IN  A   157.56.110.11
ns2a.o365filtering.com. 311 IN  A   157.56.116.52
ns4a.o365filtering.com. 311 IN  A   157.55.133.11
ns1.msft.net.   289 IN  2620:0:30::53
ns2.msft.net.   170080  IN  2620:0:32::53
ns3.msft.net.   289 IN  2620:0:34::53
ns4.msft.net.   170080  IN  2620:0:37::53

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Oct  7 07:57:41 2016
;; MSG SIZE  rcvd: 770


Regards
Daniel

RE: Multiple IPs Associated With A Single Name

[Darcy Kevin (FCA)]

Yeah, sure, just run it with your own special config file (with -c); in that 
config file, set the listen-on to an unprivileged port, and make sure all of 
the pathnames (including implicit pathnames like the pid-file) are to 
files/directories to which the unprivileged user has read and (where necessary) 
write access.

As a sanity check, I just fired up an instance on a Red Hat box, as an 
unprivileged user, listening on port 12345. It's a caching-only config, with 
our own internal-root hints, and it's resolving (internal) names just fine.


- Kevin



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Tim 
Daneliuk
Sent: Thursday, September 29, 2016 5:24 PM
To: John Miller
Cc: Bind Users
Subject: Re: Multiple IPs Associated With A Single Name

On 09/29/2016 04:18 PM, Tim Daneliuk wrote:
> On 09/29/2016 02:08 PM, John Miller wrote:
>> Hi Tim,
>>
>> AFAIK, multiple A records are the only way to return multiple IPs for 
>> a given FQDN.  there are multiple A records for a given name, BIND 
>> will return all of those records -- it'll return all the IPs.  It's 
>> up to the client in question to decide how to use that information.
>>
>> John
>>
> 
> 
> Thanks all, for responding.
> 
> One followup question.  I am currently doing some engineering work for 
> GreatBigHugeCo, wherein getting things like DNS updates done is very 
> time and paperwork intensive.  Sometimes I think it would be easier to 
> do tensor analysis with an abacus, but I digress ...
> 
> For reasons too long and complex to explain, I may want to do the 
> following and need some input on how to implement this or whether it's even 
> practical:
> 
>   - Run an instance of bind in user space so I can control all the 
> configuration without having root.
> 
>   - Forward all lookups not in my database to a "real" DNS server
> 
> 
> What I am stuck on is this:  Is there any simple (i.e., non-root) way 
> to write a client or otherwise configure userspace to go to the 
> non-standard port and run my sort of man-in-the-middle server?  Or is 
> this just a stupid idea?
> 
> 


I forgot to mention:  At least one use case for this might be a case where I 
can force the client in user space to use the DNS server and port of my 
choosing.  In that case, they won't be using the system DNS config and the
above would not apply.   However, I am unclear on whether bind can be run
as an unprivileged user on a non-standard port.

--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

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

[Darcy Kevin (FCA)]

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

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


- Kevin

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

2 zone on same network (192.168.1.0/24)

thanks

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


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

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

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

RE: about "query time" (caching) +plus

[Darcy Kevin (FCA)]

You could turn on debugging, to be sure. Or, you could just dump your cache and 
see what's in it or not, expired or not. Anything lacking a valid, unexpired 
cache entry is going to require communication with the outside to resolve, 
which is going to introduce some measure of delay.


- Kevin


-Original Message-
From: Pol Hallen [mailto:bin...@fuckaround.org] 
Sent: Monday, September 19, 2016 6:14 PM
To: Darcy Kevin (FCA); bind-users@lists.isc.org
Subject: Re: about "query time" (caching) +plus

how I audit if a query is resolved from my local DNS or by external DNS?

cheers!

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

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

RE: about "query time" (caching)

[Darcy Kevin (FCA)]

In the first case, your resolver probably had to resolve all levels of the 
hierarchy from the root all of the way down to the leaf node (root, .it, 
yahoo.it and then the leaf records). 96 msec.

In the second case, the answer was cached and so your resolver didn't have to 
talk to anything on the Internet at all. 1 msec.

In the third case, the A records had expired from the cache (since the TTL on 
those records is 300 seconds = 5 minutes), so your resolver needed to fetch a 
fresh set from the yahoo.it nameservers -- the NS records of which were most 
likely cached from the first lookup -- but it didn't need to follow the 
referral chain all of the way down from the root. 19 msec.

This all seems reasonable and expected, to me.


- Kevin
-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Pol 
Hallen
Sent: Monday, September 19, 2016 5:43 PM
To: bind-users@lists.isc.org
Subject: about "query time" (caching)

Hi all,

I'm struggling about "query time" :-/
Using bind 9.9.5, I configurated it as caching proxy:

dig yahoo.it @192.168.1.212
[...]
96msec

second time:

dig yahoo.it @192.168.1.212
[...]
1msec

seems it works but: if I waiting (ie 5 minutes) and I re-run same command, 
"query time" was increased:

19msec

why? If the record "yahoo.it" is inside cache why after 5 minutes "query time" 
is 19msec?

thanks all for help!

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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/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 (IPv6)

[Darcy Kevin (FCA)]

That's not a valid IPv6 address representation. You probably mistyped a double 
colon as a single colon in the middle of the address.

(RFC 4291)

2.2.  Text Representation of Addresses

   There are three conventional forms for representing IPv6 addresses as
   text strings:

   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to
  four hexadecimal digits of the eight 16-bit pieces of the address.
  Examples:

 ABCD:EF01:2345:6789:ABCD:EF01:2345:6789

 2001:DB8:0:0:8:800:200C:417A

  Note that it is not necessary to write the leading zeros in an
  individual field, but there must be at least one numeral in every
  field (except for the case described in 2.).

   2. Due to some methods of allocating certain styles of IPv6
  addresses, it will be common for addresses to contain long strings
  of zero bits.  In order to make writing addresses containing zero
  bits easier, a special syntax is available to compress the zeros.
  The use of "::" indicates one or more groups of 16 bits of zeros.
  The "::" can only appear once in an address.  The "::" can also be
  used to compress leading or trailing zeros in an address.



- Kevin


From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Chakrapani, Praveen CTR via bind-users
Sent: Tuesday, September 13, 2016 4:48 PM
To: 'bind-users@lists.isc.org'
Subject: forwarders (IPv6)

Hi,

I added below line to my named.conf to include IPv6 addresses to the forwarders 
list. However I am getting this error "Sep 13 10:33:06 servername named[24778]: 
[ID 873579 daemon.error] /etc/named.conf:158: expected IP address near 
'2001:1890:1C04:3000:0CB7:4432'"

"forwarders { 12.227.230.4; 12.227.230.10; 12.183.68.50; 12.183.68.51; 
12.71.76.50; 12.71.76.51; 2001:1890:1C04:3000:0CB7:4432; 
2001:1890:1C04:3000:0CB7:4433; 2001:1890:1C04:3400:0C47:4C32; 
2001:1890:1C04:3400:0C47:4C33; };
forward first;"

Please let know how to add IPv6 addresses to the forwarders list.

Thanks,
Praveen Kumar Chakrapani (CTR)
AECOM Contractor, Lead UNIX Administrator
Desk (202)326-3282

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

[Darcy Kevin (FCA)]

AXFR over UDP is explicitly undefined. See RFC 5936 Section 4.2. Given this, I 
would have expected either a FORMERR response (interpreting the request itself 
as "illegal"), or a NOTIMPL response (interpreting "undefined" as "might have 
been defined by an RFC subsequent to 5936, but I don't happen to know about 
it"). NOERROR response with TC is surprising.

IXFR over UDP is defined (RFC 1995 Section 2), but not implemented (apparently) 
by BIND. So NOTIMPL would seem appropriate.

- Kevin

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of S Carr
Sent: Thursday, August 25, 2016 4:09 PM
To: bind-users
Subject: Re: Slaves or Forwarders?

On 25 August 2016 at 21:06, Matus UHLAR - fantomas  wrote:
> just IXFRs or AXFRs too?
> Isn't edns over UDP enough in many cases?

>From what I've seen in past testing any attempt to request an AXFR against 
>BIND using UDP gets an immediate TC response.

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: Slaves or Forwarders?

[Darcy Kevin (FCA)]

>From an InfoSec standpoint, of course one would prefer to use cryptographic 
>methods of securing DNS data, but, in the absence of that, slaving could, 
>arguably, be considered more secure than forwarding, in the sense that 
>forwarding usually generates more network transactions, over time, for any 
>given resolution of any given name, and thus more chances for a bad guy to 
>successfully spoof a response and have that forged answer be cached.

One could also eke out a small measure of extra security (again, if 
cryptographic methods are for some reason unavailable) by turning off IXFR and 
thus causing all zone transfers to occur with AXFR, which is TCP-based and thus 
presumably harder to spoof. But, that's a heavy price to pay for a small 
increment of extra security. Better to go for crypto, at that point, either 
within the DNS protocol itself (e.g. TSIG, DNSSEC), by implementing (as many 
have) an out-of-band method of replicating zone data (e.g. rsync-over-ssh, 
Infoblox-style "grid replication" over OpenVPN tunnels) or by securing *all* 
communication between nameserver instances (e.g. IPSEC tunnels).


- Kevin


-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Tony 
Finch
Sent: Tuesday, August 23, 2016 11:00 AM
To: Baird, Josh
Cc: bind-users@lists.isc.org
Subject: Re: Slaves or Forwarders?

Baird, Josh  wrote:
>
> In the past, when I have had a requirement to bring a slave zone into 
> our environment; I created a slave zone on my master(s) (defining the 
> external nameserver as a master) and then created slave zones on my 
> slaves using *my* master as a master (not the master outside of my 
> environment).

> Is this method of 'sub-slaves' considered an acceptable practice?

Yes. (The new EDNS EXPIRE feature makes it a bit safer too.)

> Some folks also like to use forwarders if they don't have the 
> capability to slave the zone.  In this scenario, I would have to create a 
> 'forward'
> zone on each of my caching servers that forwards requests for 'xyz.com'
> to the up-stream nameserver authoritative for the zone.

Be careful doing that. The target forwarders have to be recursive servers.

This matters if there is a delegated subdomain; if you are forwarding to an 
authoritative-only server which returns a referral, BIND will be upset that it 
did not get the final answer it expected.

> I would think that slaving the zone would be the preferred method, 
> since my master/slaves could still serve the zone if the 
> up-stream/forwarder becomes unreachable (until my slave expires).

Yes, slaving can be more robust. But forwarding can be simpler.

Tony.
--
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: Easterly 6 to gale 8 in east, otherwise northerly or northeasterly
4 or 5, increasing 6 at times. Slight or moderate, occasionally rough in east.
Showers. Good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/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 first and fallback not working

[Darcy Kevin (FCA)]

Look in your logs at the time of named startup to see if your root-server 
priming failed at that time.


- kevin


-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
ma...@nucleus.it
Sent: Tuesday, August 23, 2016 6:42 AM
To: bind-users@lists.isc.org
Subject: forward first and fallback not working

Hi,
bind 9.10.3_p4 with this global option:

forward first;

forwarders {
   8.8.8.8;
};

If i dig from localhost or any client and 8.8.8.8 answers all is ok but if 
8.8.8.8 is unreachable or it doesn't respond, bind doesn't fallback on himslef 
asking to root server etc .

This is not expected.
Anyone with this behavior ?

best regards
Marco
___
Please visit https://lists.isc.org/mailman/listinfo/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 used as resolver: matching the source ip

[Darcy Kevin (FCA)]

Or just check the RFCs. 

https://www.ietf.org/rfc/rfc5452.txt

- Kevin

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mukund 
Sivaraman
Sent: Friday, August 19, 2016 2:27 AM
To: pm8...@t-online.de
Cc: bind-users@lists.isc.org
Subject: Re: bind used as resolver: matching the source ip

On Thu, Aug 18, 2016 at 11:27:01AM +0200, pm8...@t-online.de wrote:
> Dear all,
>  
> As far as I understand, BIND is not only used for authoritative name 
> servers, but is also often used as a (recursive) resolver.
> When receiving a response to a DNS query, does BIND match the source 
> ip of the response to the destination ip of the query and discard the 
> response if they do not match? Does it match the ports?
> I.e. apart from checking
> query.transactionID == response.transactionID does BIND check for 
> query.destinationIP == response.sourceIP and query.destinationPort == 
> response.sourcePort?
> Can you point me to the function in the source code where this check 
> does or does not happen?

Yes, otherwise offpath cache poisoning would be possible. BIND as resolver not 
only matches source port, but also the question and DNS cookie among other 
things.

You should be able to find the address and port matching code somewhere within 
lib/dns/dispatch.c. Question and cookie matching code should be found in 
lib/dns/resolver.c.

Mukund
___
Please visit https://lists.isc.org/mailman/listinfo/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: Selective forwarding from an internal only name server

[Darcy Kevin (FCA)]

Well, the cost/benefits/risks of separating authoritative and recursive on 
different *servers* (as opposed to different NICs, views, or whatever) is 
actually a hotly-debated topic among experts. I know some non-DNS-expert 
opinions, from the InfoSec side of the house, consider hardware-level 
separation "ideal", but frankly, I don't think they understand the concepts of 
NIC- or view-level separation, and need to be edumacated. Personally, I prefer 
a larger number of multi-role boxes, with view separation. The larger number of 
boxes means more availability and resilience against, say, Denial of Service 
attacks, which can target recursive service *or* authoritative service *or* 
both.

By the way, the original poster never said that he was hosting any zones 
authoritatively to the Internet on NS1, so why would you assume that he is? He 
said only that it served "external clients", but those could be *recursive* 
clients, for all we know.

That having been said, I concur with your technical recommendations.

- Kevin



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of S Carr
Sent: Thursday, August 18, 2016 4:31 AM
To: BIND Users
Subject: Re: Selective forwarding from an internal only name server

On 18 August 2016 at 01:04, anup albal  wrote:
> Does that mean I setup another forwarding zone called microsoft.com or 
> sharepoint.microsoft.com or both?

Ideally you should setup a completely separate caching/forwarding server and 
not be using the external DNS box (NS1) for this purpose.

On the box you are forwarding the queries to (NS1) you need to enable recursion 
and specify an ACL for recursion to limit it to only allowing recursion from 
the internal DNS1 box.

On the internal DNS box (DNS1) also make sure recursion is enabled and an ACL 
in place allowing your client subnets, and configure forward zones for 
sharepoint.com and microsoft.com zones (and any other zones needed by the 
sharepoint service) to point at the NS1 box.
___
Please visit https://lists.isc.org/mailman/listinfo/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: Selective forwarding from an internal only name server

[Darcy Kevin (FCA)]

As I read it, you have to buy the "flattening" as an extra service from 
CloudFlare. Their default is to give CNAME at the apex, intentionally violating 
RFCs.

What a concept: charging extra for RFC-compliance.


- Kevin


-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Barry 
Margolin
Sent: Wednesday, August 17, 2016 9:08 PM
To: comp-protocols-dns-b...@isc.org
Subject: Re: Selective forwarding from an internal only name server

In article <mailman.301.1471466524.15653.bind-us...@lists.isc.org>,
 "Darcy Kevin (FCA)" <kevin.da...@fcagroup.com> wrote:

> Barry,
>   Cloudflare has been doing this for a while, so that their customers 
> won't be "limited by the DNS specifications (RFCs)" . 
> Having done that, they were compelled to offer another service -- so-called 
> "CNAME flattening"
> -- to fix the brokenness that's caused by their base offering.
> 
> See
> https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flatt
> ening-RF C-compliant-support-for-CNAME-at-the-root
> 
> I think Akamai also offers something similar.

But these don't work by sending an actual CNAME record. The server that 
implements flattening looks ip the IP of the target, and returns it as an A 
record for the domain.

That's why Cloudflare's method is "RFC-compliant", but what MS is doing with 
sharepoint.com is not.

> 
>   - Kevin
> 
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf 
> Of Barry Margolin
> Sent: Wednesday, August 17, 2016 4:34 PM
> To: comp-protocols-dns-b...@isc.org
> Subject: Re: Selective forwarding from an internal only name server
> 
> In article <mailman.299.1471461214.15653.bind-us...@lists.isc.org>,
>  "Darcy Kevin (FCA)" <kevin.da...@fcagroup.com> wrote:
> 
> > Well, sharepoint.com is a CNAME to sharepoint.microsoft.com, so you 
> > might need to make arrangements for that to be resolvable as well.
> 
> That doesn't seem valid to begin with. The .COM zone has delegation NS 
> records for sharepoint.com. Having a CNAME record for the same name is wrong.
> 
> --
> 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

--
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: Selective forwarding from an internal only name server

[Darcy Kevin (FCA)]

Barry,
Cloudflare has been doing this for a while, so that their customers 
won't be "limited by the DNS specifications (RFCs)" . Having done 
that, they were compelled to offer another service -- so-called "CNAME 
flattening" -- to fix the brokenness that's caused by their base offering.

See 
https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root

I think Akamai also offers something similar.

- Kevin

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Barry 
Margolin
Sent: Wednesday, August 17, 2016 4:34 PM
To: comp-protocols-dns-b...@isc.org
Subject: Re: Selective forwarding from an internal only name server

In article <mailman.299.1471461214.15653.bind-us...@lists.isc.org>,
 "Darcy Kevin (FCA)" <kevin.da...@fcagroup.com> wrote:

> Well, sharepoint.com is a CNAME to sharepoint.microsoft.com, so you 
> might need to make arrangements for that to be resolvable as well.

That doesn't seem valid to begin with. The .COM zone has delegation NS records 
for sharepoint.com. Having a CNAME record for the same name is wrong.

--
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: Selective forwarding from an internal only name server

[Darcy Kevin (FCA)]

Well, sharepoint.com is a CNAME to sharepoint.microsoft.com, so you might need 
to make arrangements for that to be resolvable as well.



- Kevin

P.S. I don't think it matters - and I'm too lazy to check right now - but it's 
remotely possible that the trailing period in your forwarding-zone definition 
("sharepoint.com.") might be problematic. Easy enough to confirm/deny.

[FCA_Pantone_email]
--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of anup 
albal
Sent: Wednesday, August 17, 2016 6:00 AM
To: bind-users@lists.isc.org
Subject: Selective forwarding from an internal only name server

Hi

First up apologies if this is not the right list to email and for a long email. 
I am hoping you can give me a clue as to what I am doing wrong here? Or may be 
this is not supposed to work at all.

We have an internal only DNS server (dns1) with fake root zone. i.e a fake file 
for the zone "."  This serves all internal clients.
We are running 9.6-ESV-R11-P2 for this.

And we also have an external only DNS (ns1) which can talk to the internet for 
DNS queries and serves external clients.

Now we have a requirement to have certain domains (e.g sharepoint.com) resolved 
on clients being served by dns1.

On dns1 I have setup a forward only zone called 'sharepoint.com' with ns1 set 
as the forwarder.
And on the fake root zone file, I have added an entry for sharepoint like below
sharepoint.com.  NS ns1.org.domain.name.au.

when i run a dig +trace sharepoint.com from dns1 I can resolve sharepoint.com
But when i run it from an internal client it gets a Non-authoritative: No answer

Below are my snippets of my named.conf on dns1 (internal)

options {
directory "/var/dns";
forwarders { ip.of.ns1; };
listen-on  { ip.of.dns1; 127.0.0.1; };
query-source address ip.of.dns1;
notify-source ip.of.dns1;
transfer-source ip.of.dns1;
allow-transfer { xxx.xxx/16; };
transfer-format one-answer;// BIND9 (deal with Windows Server 2003)

};

<.>
zone "." in {
type master;
file "fake/root";
};

zone "." in {
type hint;
file "/var/dns/fake/named.root";
};
zone "sharepoint.com." in {
type forward;
forward only;
forwarders {ip.of.ns1;};
};

The file fake/root has entries like below (ip and domain names changed for 
security)

$TTL 86400
; NOTE:  TTL based on from Bind8 SOA record
;
; This file contains *fake* DNS Resource Records for the root domain (.)
;

.   IN  SOA dns1.org.domain.name.au.
xxx.dns1.org.domain.name.au.  (
 2016081608  ; serial
 10800   ; refresh
 3600; retry
 360 ; expire
 86400 ) ; minimum

.   NS  dns1.org.domain.name.au.
;.  NS  dns2.org.domain.name.au.

com.au. NS  dns1.org.domain.name.au.
sharepoint.com. NS  ns1.org.domain.name.au.
difforg.diffdomain.au. NS  dns1.org.domain.name.au.

0.0.127.in-addr.arpa.   NS  dns1.org.domain.name.au.

xxx.xxx.in-addr.arpa.   NS  dns1.org.domain.name.au.

localhost.  A   127.0.0.1

; Glue
dns1.org.domain.name.au. A  ip.of.dns1
ns1.org.domain.name.au.  A  ip.of.ns1
;dns2.org.domain.name.au. A  xxx.xxx.xxx.xxx

The root hints file (named.root) has below

.   3600IN NS   dns1.org.domain.name.au
dns13600A   ip.of.dns1


nslookup on a client returns this
nslookup sharepoint.com
Server: ip.of.dns1
Address:ip.of.dns1#53

Non-authoritative answer:
*** Can't find sharepoint.com: No answer

And running dig on a client returns this
 dig +trace sharepoint.com

; <<>> DiG 9.3.4-P1 <<>> +trace sharepoint.com
;; global options:  printcmd
.   86400   IN  NS  dns1.org.domain.name.au.
;; Received 69 bytes from ip.of.dns1#53(ip.of.dns1) in 1 ms

sharepoint.com. 86400   IN  NS  ns1.org.domain.name.au.
;; Received 84 bytes from ip.of.dns1#53(dns1.org.domain.name.au) in 0 ms

;; connection timed out; no servers could be reached


Regards

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

[Darcy Kevin (FCA)]

Forwarding is a different beast from "stub" (recursive rather than iterative 
resolution).

I'd look at "static-stub", if your NS list is overgrown with 
useless/unreachable stuff. It's configured basically the same way as 
forwarding, but without making the paradigm shift (and possible unforeseen 
consequences) from iterative to recursive resolution.

http://jpmens.net/2011/01/25/binds-new-static-stub-zone-type/
https://lists.isc.org/pipermail/bind-users/2012-September/088719.html

If you only have a *few*, relatively-static set of unreachables, you might 
consider listing just those ones as "bogus".

- Kevin

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ray Van 
Dolson
Sent: Saturday, August 13, 2016 8:29 AM
To: bind-users@lists.isc.org
Subject: Stub Zone Behavior?

Have a resolver at a branch office with a view containing a stub zone as 
follows:

zone "domain.com." IN {
type stub;
masters { 10.216.11.6; 10.58.4.1; 10.50.4.32; };
file "stub/domain.com";
forwarders {};
};

Other notes:

- "domain.com" is an Active Directory zone.
- Running bind-9.8.2-0.47.rc1.el6.x86_64 (RHEL6)

This setup seemed to work fine for many months, but within the last two or so 
has randomly started returning no answers for only certain queries (well the 
SOA stuff is returned) until I rndc flush on the system after which response 
returns to normal for a period of time.

After trying a few things without success, I changed the zone type to forward 
instead of stub (with the servers used as masters in the stub config as the 
forwarders) and this has seemed to solved the problem.

As I understand it, stub zones work by pulling down SOA, NS and "glue"
for the NS from one of the masters into a local zone file and then queries to 
the domain are answered by querying one of the authoritative servers defined in 
the stub zone.

My working theory is that BIND will randomly choose one of the NS servers to 
get an answer from, and since our NS list is very long with the servers 
scattered across the globe, perhaps BIND chooses one which doesn't respond 
quickly enough or at all (or maybe badly?) and then caches that negative or 
absent response.

Probably in this case the forward type works just as well for our local clients 
at the office (I believe answers for "forward" zones can also be cached 
locally...), so am inclined to stand pat with this config but would still love 
to understand what might have caused the original stub setup to fail.

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

[Darcy Kevin (FCA)]

True, strictly from a per-hop latency standpoint, there shouldn't be much 
difference between forwarding a packet or forwarding a DNS query.

Having said that -- and I'm sure the BIND developers could elaborate further on 
this -- I know that there's big difference between processing *packets*, from, 
say, a routing standpoint, which customized ASIC-level hardware can do to the 
tune of millions per second, and processing *queries*, which are much 
higher-level constructs, with a lot more variation, more levels of parsing, 
disassembly, re-assembly, validation, etc. When you have multi-hop DNS 
forwarding, you're using up significant resources on multiple computing devices 
at once, in ways that don't necessarily lend themselves to optimization in 
hardware. It ends up being the opposite of parallelism, i.e. using the 
resources of multiple devices to accomplish something that could, with only 
configuration changes, be accomplished with the resources of only one device.

At the risk of sounding xenophobic, there seems to be a mindset among certain 
cultures that forwarding is "natural", and, in contrast, having DNS instances 
talk to each other directly is somehow "artificial". I've had this conversation 
many times with many of my European counterparts over the years, and we just 
seem to view things differently. One could speculate on the difference in world 
view -- submission to higher authority, perhaps? Hierarchical social 
organization? I don't know -- I don't claim any expertise whatsoever in 
sociology, cognitive psychology, or related fields. But for me, and I think 
most people in my (North American) culture -- possibly because we tend more 
towards individualism and/or egalitarianism? -- having DNS instances talk 
*directly* to each other, as "equals" or "peers", is much more natural than one 
DNS instance relying upon another to handle all of its resolution needs (thus 
making the first instance subservient, in a sense, to the second), which then 
relies on another, and to another, and so on, in a daisy chain.

Again, maybe it's just a different mindset/world-view. Or, perhaps I'm 
over-generalizing a cultural difference from a relatively-small sample of 
conversations. But, as I touched on in my second paragraph, there may be some 
objective reasons to eschew forwarding, particularly multi-hop forwarding.


- Kevin


-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Willmann, Robert
Sent: Friday, August 12, 2016 1:33 AM
To: bind-users@lists.isc.org
Subject: RE: Delegation questions

Kevin Darcy wrote:
> 
> In any case, multi-hop forwarding is always the least-preferred option.
> 

I wonder for which reason do you think this.

Of course, any forwarding adds a additional hop and therefore additional delay 
and an additional possible point of failure.
But this is true for any network-connection.

So, what do you think are the DNS-specific downsides of forwarding?
The only thing that comes to mind if I think about downsides of forwarding is 
that, if something goes wrong, the client only gets a generic SERVFAIL as 
errormessage instead of a specific explanation what exactly went wrong.

Do you see other downsides to forwarding?


Mit freundlichen Grüßen
Robert Willmann

--
Commerzbank AG
Group Information Technology
GS-IT 8.2.3 Core Services

Postanschrift: 60261 Frankfurt am Main
Geschäftsräume: Mainzer Landstr. 151, 60327 Frankfurt am Main
Tel.:   +49 69 136 - 290 71
Fax:+49 69 136 - 590 71 
robert.willm...@commerzbank.com

Commerzbank AG, Frankfurt am Main http://www.commerzbank.de Pflichtangaben 
http://www.commerzbank.de/pflichtangaben


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

[Darcy Kevin (FCA)]

Sorry, I left out the option of fixing the firewall rules.

Depending on your performance/resilience requirements, available bandwidth, 
latency, query patterns, etc. this may or may not be preferable to slaving the 
zone to your site. It’s hard to say without knowing a lot of details about your 
environment.

In any case, multi-hop forwarding is always the least-preferred option.



- Kevin


From: Darcy Kevin (FCA)
Sent: Thursday, August 11, 2016 1:44 PM
To: bind-us...@isc.org
Subject: RE: Delegation questions

No, you would never get rid of a valid delegation of a child zone; why *reduce* 
the resolvability of that zone? Whatever you do to get around this connectivity 
issue would be *in*addition*to* the delegation, not as a replacement for it.

That having been said, I outlined your options in a previous post:

· If you can make something on your site authoritative for the zone, 
then do that. That gives you more options (stub zone, multi-hop slaving, or – 
if you can convince the owners to publish appropriate NS records – regular 
iterative resolution will work without any special named.conf configuration at 
all).

· If you can’t make *anything* at your site authoritative for the zone, 
then your only option is for your servers that *don’t* have connectivity to a 
source of resolution for the zone, to forward to one or more servers that *do* 
have the necessary connectivity. But now we’re talking about multi-hop 
recursive resolution, and that’s definitely sub-optimal.

- Kevin


From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Bob 
McDonald
Sent: Thursday, August 11, 2016 1:14 PM
Cc: bind-us...@isc.org<mailto:bind-us...@isc.org>
Subject: Re: Delegation questions

Let me be a bit more clear...
This is strictly internal. There are no external clients or servers involved. 
All three of the servers have recursion turned ON.
Server A has a domain (example.com<http://example.com>.)
example.com<http://example.com>. has an NS record that points to server B and 
delegate child.example.com<http://child.example.com>. (yes there's really two, 
this is just an example)
Server B is at another company. (probably connected via some sort of IPSEC 
tunnel)
Server C has a slave copy of example.com<http://example.com>. from server A 
(and the associated NS record delegating 
child.example.com<http://child.example.com>. to server B)
Server C is at another site at the same company as server A
Currently, clients sending queries for domain 
child.example.com<http://child.example.com>. to server A get good results.
However, clients sending queries for domain 
child.example.com<http://child.example.com>. to server C get SERVFAIL because 
server C has no access to server B. (I'm guessing there is a firewall issue)
The question is if I get rid of the delegation and put in a stub zone on server 
A pointing to child.example.com<http://child.example.com>. on server B, can I 
use forwarders for child.example.com<http://child.example.com>. on server C to 
point at server A for resolution of 
child.example.com<http://child.example.com>.? (Will server A get answers 
directly from server B or will server A simply refer me to server B?)
Hope that's clearer.
Bob


On Thu, Aug 11, 2016 at 11:52 AM, Matthew Pounsett 
<m...@conundrum.com<mailto:m...@conundrum.com>> wrote:


On 11 August 2016 at 09:13, Bob McDonald 
<bmcdonal...@gmail.com<mailto:bmcdonal...@gmail.com>> wrote:
I have a child domain that is delegated to a second site. Pretty 
straightforward situation. In the parent zone I have NS records that point to 
the DNS servers at the second site.
The issue comes up when a slaved copy of the parent domain is running at a 
third site and that third site doesn't have a rule in their firewall allowing 
DNS access to the second site (where the child domain is delegated).
The question is this; can I use stub zones to reference the child domain on the 
master server (instead of delegation) and the use forwarding at the third site 
to direct queries for the child domain through the master server?
I hope the picture I've tried to describe is somewhat clear.

If the setup is exactly as you describe, then there's probably no reason for a 
name server authoritative for the parent zone to ever need to contact a server 
authoritative for the child zone.  Delegation from A to B doesn't imply direct 
communication between A and B.

That said, you never know where on the Internet queries for a zone will arrive 
from.  If you want the Internet at large to be able to resolve names in your 
zone, then you can't firewall yourself off from parts of the Internet.

If any of the servers in this scenario are also acting as recursive servers, 
then you have the same

RE: Delegation questions

[Darcy Kevin (FCA)]

No, you would never get rid of a valid delegation of a child zone; why *reduce* 
the resolvability of that zone? Whatever you do to get around this connectivity 
issue would be *in*addition*to* the delegation, not as a replacement for it.

That having been said, I outlined your options in a previous post:

· If you can make something on your site authoritative for the zone, 
then do that. That gives you more options (stub zone, multi-hop slaving, or – 
if you can convince the owners to publish appropriate NS records – regular 
iterative resolution will work without any special named.conf configuration at 
all).

· If you can’t make *anything* at your site authoritative for the zone, 
then your only option is for your servers that *don’t* have connectivity to a 
source of resolution for the zone, to forward to one or more servers that *do* 
have the necessary connectivity. But now we’re talking about multi-hop 
recursive resolution, and that’s definitely sub-optimal.

- Kevin


From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Bob 
McDonald
Sent: Thursday, August 11, 2016 1:14 PM
Cc: bind-us...@isc.org
Subject: Re: Delegation questions

Let me be a bit more clear...
This is strictly internal. There are no external clients or servers involved. 
All three of the servers have recursion turned ON.
Server A has a domain (example.com.)
example.com. has an NS record that points to server B and 
delegate child.example.com. (yes there's really two, 
this is just an example)
Server B is at another company. (probably connected via some sort of IPSEC 
tunnel)
Server C has a slave copy of example.com. from server A 
(and the associated NS record delegating 
child.example.com. to server B)
Server C is at another site at the same company as server A
Currently, clients sending queries for domain 
child.example.com. to server A get good results.
However, clients sending queries for domain 
child.example.com. to server C get SERVFAIL because 
server C has no access to server B. (I'm guessing there is a firewall issue)
The question is if I get rid of the delegation and put in a stub zone on server 
A pointing to child.example.com. on server B, can I 
use forwarders for child.example.com. on server C to 
point at server A for resolution of 
child.example.com.? (Will server A get answers 
directly from server B or will server A simply refer me to server B?)
Hope that's clearer.
Bob


On Thu, Aug 11, 2016 at 11:52 AM, Matthew Pounsett 
> wrote:


On 11 August 2016 at 09:13, Bob McDonald 
> wrote:
I have a child domain that is delegated to a second site. Pretty 
straightforward situation. In the parent zone I have NS records that point to 
the DNS servers at the second site.
The issue comes up when a slaved copy of the parent domain is running at a 
third site and that third site doesn't have a rule in their firewall allowing 
DNS access to the second site (where the child domain is delegated).
The question is this; can I use stub zones to reference the child domain on the 
master server (instead of delegation) and the use forwarding at the third site 
to direct queries for the child domain through the master server?
I hope the picture I've tried to describe is somewhat clear.

If the setup is exactly as you describe, then there's probably no reason for a 
name server authoritative for the parent zone to ever need to contact a server 
authoritative for the child zone.  Delegation from A to B doesn't imply direct 
communication between A and B.

That said, you never know where on the Internet queries for a zone will arrive 
from.  If you want the Internet at large to be able to resolve names in your 
zone, then you can't firewall yourself off from parts of the Internet.

If any of the servers in this scenario are also acting as recursive servers, 
then you have the same problem;  you never know where on the Internet an 
authoritative server you need to speak to is going to be, so you can't firewall 
your recursive server off from speaking to parts of the Internet and expect it 
to work reliably.




Regards,
Bob

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

[Darcy Kevin (FCA)]

The bottom line is: any resolver which is using iterative resolution (as 
opposed to just forwarding) to resolve names in a zone, needs to be able to 
talk to at least *some* of the published nameservers for the zone, or to 
“override” the regular referral-chain using something like a “stub” zone. But, 
be aware, even if you define “stub”, those queries are going to be 
*non-recursive* (RD=0), so they are not forwardable. In other words, you can’t 
stub part of the way, and forward the rest of the way. That simply doesn’t work.

If you want to “slingshot” your resolution through another box, then really 
your *only* choice is recursive resolution, and in BIND terms, that implies 
defining one or more “forwarders”.

That being said, it’s a terrible way to do things. The firewalls should be 
opened up so that nameservers can talk to each other directly. Direct 
nameserver-to-nameserver communication is the assumption upon which the DNS 
resolution architecture is based. Forwarding is just an ugly kludge to deal 
with connectivity challenges.

Another option to consider: why don’t you make your “parent” nameservers 
authoritative (e.g. by setting up master/slave) for the “child” zone as well, 
and publish them in the NS records of the zone? That would be better than 
forwarding. If you can make them authoritative, but for some reason *cannot* 
publish them in the NS records, then at least that gets you far enough to be 
able to use a “stub” zone on the “third site”.



- Kevin

[FCA_Pantone_email]
--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matthew 
Pounsett
Sent: Thursday, August 11, 2016 12:52 PM
To: Bob McDonald
Cc: bind-us...@isc.org
Subject: Re: Delegation questions



On 11 August 2016 at 09:13, Bob McDonald 
> wrote:
I have a child domain that is delegated to a second site. Pretty 
straightforward situation. In the parent zone I have NS records that point to 
the DNS servers at the second site.
The issue comes up when a slaved copy of the parent domain is running at a 
third site and that third site doesn't have a rule in their firewall allowing 
DNS access to the second site (where the child domain is delegated).
The question is this; can I use stub zones to reference the child domain on the 
master server (instead of delegation) and the use forwarding at the third site 
to direct queries for the child domain through the master server?
I hope the picture I've tried to describe is somewhat clear.

If the setup is exactly as you describe, then there's probably no reason for a 
name server authoritative for the parent zone to ever need to contact a server 
authoritative for the child zone.  Delegation from A to B doesn't imply direct 
communication between A and B.

That said, you never know where on the Internet queries for a zone will arrive 
from.  If you want the Internet at large to be able to resolve names in your 
zone, then you can't firewall yourself off from parts of the Internet.

If any of the servers in this scenario are also acting as recursive servers, 
then you have the same problem;  you never know where on the Internet an 
authoritative server you need to speak to is going to be, so you can't firewall 
your recursive server off from speaking to parts of the Internet and expect it 
to work reliably.




Regards,
Bob

___
Please visit https://lists.isc.org/mailman/listinfo/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: allow-query does not seem to be working

[Darcy Kevin (FCA)]

As already noted, allow-query will cause you to send back a REFUSED response. 
That’s sort of the whole point of the REFUSED RCODE.

If you want to not send back any response *whatsoever*, then take a look at the 
“blackhole” statement, but, honestly, this kind of “drop” function may, 
depending on network topology, be more efficiently performed in your firewall 
or IDS/IPS.

Be aware that a client that doesn’t get a response may retry the query, so 
simply “dropping” queries may ultimately prove counter-productive.


- Kevin

[FCA_Pantone_email]
--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Frank 
Even
Sent: Saturday, August 06, 2016 4:42 PM
To: bind-users
Subject: allow-query does not seem to be working

I have a group of servers serving out multiple addresses via anycast.  I've 
been made aware that an IP outside of our network is hitting the boxes with 
queries, and we're returning data to the client.

With allow-query and allow-recursion locked to our subnets, this outside host 
is still getting responses, and I'm trying to figure out why.

named.conf snippet:

allow-query { mynets; };
allow-recursion { mynets; };

Yet in response to a host not from one of the subnets allowed, we're getting 
requests and returning some kind of response:

# tcpdump -i any -nvv src $myhost and dst 156.154.100.3
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 
65535 bytes
13:37:30.578020 IP (tos 0x0, ttl 64, id 5059, offset 0, flags [none], proto UDP 
(17), length 81)
$myhost.33941 > 156.154.100.3.domain: [bad udp cksum f39c!] 54976 [1au] A? 
www.sparknewspaper.co.uk. ar: . OPT 
UDPsize=4096 OK (53)
13:37:30.578025 IP (tos 0x0, ttl 64, id 5059, offset 0, flags [none], proto UDP 
(17), length 81)
$myhost.33941 > 156.154.100.3.domain: [bad udp cksum f39c!] 54976 [1au] A? 
www.sparknewspaper.co.uk. ar: . OPT 
UDPsize=4096 OK (53)
13:37:30.644502 IP (tos 0x0, ttl 64, id 5060, offset 0, flags [none], proto UDP 
(17), length 79)
$myhost.61737 > 156.154.100.3.domain: [bad udp cksum fef9!] 7832 [1au] A? 
silverstonepaint.co.uk. ar: . OPT UDPsize=4096 
OK (51)
13:37:30.644505 IP (tos 0x0, ttl 64, id 5060, offset 0, flags [none], proto UDP 
(17), length 79)
$myhost.61737 > 156.154.100.3.domain: [bad udp cksum fef9!] 7832 [1au] A? 
silverstonepaint.co.uk. ar: . OPT UDPsize=4096 
OK (51)
13:37:30.722628 IP (tos 0x0, ttl 64, id 5061, offset 0, flags [none], proto UDP 
(17), length 68)


If an IP is not allowed as part of an "allow-query" statement, should the name 
server still be returning any responses?

BIND version - BIND 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6
___
Please visit https://lists.isc.org/mailman/listinfo/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 response cache ttl (--enable-cache-ttl)

[Darcy Kevin (FCA)]

That's only a problem if the clients are constantly looking up the name, right? 
If they're looking it up only _occasionally_, with some degree of entropy, then 
the query load gets spread out.

So, in those cases, implement something on the client side that pre-expires the 
cache entry with some degree of randomness factored in. Pre-expiring cache 
entries is entirely within the standards and the original concept of how DNS 
response caching works (since, after all, dumping one's cache can't be 
prevented if the client restarts or reboots). Sure, pre-expiration may result 
in an overall increase in query traffic, but it smooths out the spikes to the 
intermediate resolvers, which is what we're worried about here. In time, the 
data owners will catch on that their cache entries are being pre-expired; if 
they care about that, they'll bump up the TTLs to compensate, eventually we 
reach a point of equilibrium.


- Kevin




-Original Message-
From: Mark Andrews [mailto:ma...@isc.org] 
Sent: Thursday, August 04, 2016 7:47 PM
To: Darcy Kevin (FCA)
Cc: bind-users@lists.isc.org
Subject: Re: change response cache ttl (--enable-cache-ttl)


In message <de89e87d93dc4c7dad81bcc0ddae3...@mxph4chrw.fgremc.it>, "Darcy Kevin 
(FCA)" writes:
> "many client have caused a burst DNS traffic" is not much of a problem 
> statement, honestly.
>
> What does this patch add, of value, that isn't already covered by 
> "max-cache-ttl"?
>
> If you're trying to allow the operators of intermediate resolvers to 
> override the intentions of the data owner, by enforcing a *minimum* 
> TTL, then I have to say that's a really bad idea. The data owner sets 
> their TTL for a reason, and if it's low, it's probably because the 
> infrastructure is very dynamic. Forcing data to be kept after the data 
> owners' TTL, risks keeping "stale" data in the client, and this will 
> likely have a negative impact on the user experience. It might even 
> have security implications, because maybe that resource (e.g. IP 
> address) isn't trusted any more. You don't want clients connecting to 
> an untrusted resource, do you? Who would have legal or criminal 
> liability, if that happened?
>
>   - Kevin

The problem is when you have a million clients each with a local cache they all 
expire the record simultaniously and if it is a popular address then you get a 
million DNS queries in the second after the ttl has expired as all those local 
caches refresh.

This is a attempt to distribute the query load from those caches uniformly 
rather than have a peak load every ttl seconds.

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

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

RE: change response cache ttl (--enable-cache-ttl)

[Darcy Kevin (FCA)]

So, fix the TTLs on the RBLs, sheesh! Pathological use cases don't warrant 
deviation from standard.

- Kevin


-Original Message-
From: Reindl Harald [mailto:h.rei...@thelounge.net] 
Sent: Thursday, August 04, 2016 2:32 PM
To: Darcy Kevin (FCA); bind-users@lists.isc.org
Subject: Re: change response cache ttl (--enable-cache-ttl)



Am 04.08.2016 um 20:27 schrieb Darcy Kevin (FCA):
> "many client have caused a burst DNS traffic" is not much of a problem 
> statement, honestly.
>
> What does this patch add, of value, that isn't already covered by 
> "max-cache-ttl"?
>
> If you're trying to allow the operators of intermediate resolvers to override 
> the intentions of the data owner, by enforcing a *minimum* TTL, then I have 
> to say that's a really bad idea. The data owner sets their TTL for a reason, 
> and if it's low, it's probably because the infrastructure is very dynamic. 
> Forcing data to be kept after the data owners' TTL, risks keeping "stale" 
> data in the client, and this will likely have a negative impact on the user 
> experience. It might even have security implications, because maybe that 
> resource (e.g. IP address) isn't trusted any more. You don't want clients 
> connecting to an untrusted resource, do you? Who would have legal or criminal 
> liability, if that happened?

no, it is not by definition, it depends as always on the use-case

on a public MX (inbound mail) hence most people are using unbound instead of 
named because it *has* such a setting to overcome the sort TTL of 5 secods from 
many RBL's and if your resolver has a specific usecase on a specific workload 
it's clearly OK to set this to 60 seconds or so

___
Please visit https://lists.isc.org/mailman/listinfo/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 response cache ttl (--enable-cache-ttl)

[Darcy Kevin (FCA)]

"many client have caused a burst DNS traffic" is not much of a problem 
statement, honestly.

What does this patch add, of value, that isn't already covered by 
"max-cache-ttl"?

If you're trying to allow the operators of intermediate resolvers to override 
the intentions of the data owner, by enforcing a *minimum* TTL, then I have to 
say that's a really bad idea. The data owner sets their TTL for a reason, and 
if it's low, it's probably because the infrastructure is very dynamic. Forcing 
data to be kept after the data owners' TTL, risks keeping "stale" data in the 
client, and this will likely have a negative impact on the user experience. It 
might even have security implications, because maybe that resource (e.g. IP 
address) isn't trusted any more. You don't want clients connecting to an 
untrusted resource, do you? Who would have legal or criminal liability, if that 
happened?

- Kevin


-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of SUKMOON 
LEE
Sent: Thursday, August 04, 2016 7:25 AM
To: bind-users@lists.isc.org
Subject: change response cache ttl (--enable-cache-ttl)

Hello Sirs,

I am Sukmoon Lee, a software developer and network engineer in South Korea.

Recently, most clients(smart phone) have a local DNS cache.
The Cache DNS TTL  affects the client cache expiration time domain. So many 
clients have caused a burst DNS traffic.
In order to solve this issue made the following patches for 9.9.9-P2 ISC BIND.

It was modified so as not to affect the original code as much as possible.
This function is working using '--enable-cache-ttl' option.
So cache DNS responses a stored cache TTL.

My question is wondering whether to require this function.
So, please check code that there are no problems.

Thank you.

Sukmoon Lee






diff -Nur bind-9.9.9-P2/bin/named/query.c bind-9.9.9-P2-ttl/bin/named/query.c
--- bind-9.9.9-P2/bin/named/query.c 2016-07-14 08:54:33.0 +0900
+++ bind-9.9.9-P2-ttl/bin/named/query.c 2016-07-27 11:05:46.414020726 +0900
@@ -2302,11 +2302,15 @@
dns_rdatalist_init(dns64_rdatalist);
dns64_rdatalist->rdclass = dns_rdataclass_in;
dns64_rdatalist->type = dns_rdatatype_;
+#ifdef USE_CACHE_STORED_TTL
+   dns64_rdatalist->ttl = rdataset->base_ttl; #else
if (client->query.dns64_ttl != ISC_UINT32_MAX)
dns64_rdatalist->ttl = ISC_MIN(rdataset->ttl,
   client->query.dns64_ttl);
else
dns64_rdatalist->ttl = ISC_MIN(rdataset->ttl, 600);
+#endif
 
if (RECURSIONOK(client))
flags |= DNS_DNS64_RECURSIVE;
@@ -2360,6 +2364,9 @@
result = dns_rdatalist_tordataset(dns64_rdatalist, dns64_rdataset);
if (result != ISC_R_SUCCESS)
goto cleanup;
+#ifdef USE_CACHE_STORED_TTL
+   dns64_rdataset->base_ttl = rdataset->base_ttl; #endif
client->query.attributes |= NS_QUERYATTR_NOADDITIONAL;
dns64_rdataset->trust = rdataset->trust;
query_addrdataset(client, mname, dns64_rdataset); @@ -5456,7 +5463,11 @@
dns_rdataset_current(, );
result = dns_rdata_tostruct(, , NULL);
RUNTIME_CHECK(result == ISC_R_SUCCESS);
+#ifdef USE_CACHE_STORED_TTL
+   ttl = ISC_MIN(rdataset.base_ttl, soa.minimum); #else
ttl = ISC_MIN(rdataset.ttl, soa.minimum);
+#endif
 
 cleanup:
if (dns_rdataset_isassociated())
@@ -6984,10 +6995,14 @@
 * decremented to zero or if there was no negative cache
 * ttl in the answer.
 */
+#ifdef USE_CACHE_STORED_TTL
+   client->query.dns64_ttl = rdataset->base_ttl; #else
if (rdataset->ttl != 0)
client->query.dns64_ttl = rdataset->ttl;
else if (dns_rdataset_first(rdataset) == ISC_R_SUCCESS)
client->query.dns64_ttl = 0;
+#endif
query_releasename(client, );
dns_db_detachnode(db, );
rdataset = NULL;
@@ -7510,7 +7525,11 @@
 */
client->query.dns64_ = rdataset;
client->query.dns64_sig = sigrdataset;
+#ifdef USE_CACHE_STORED_TTL
+   client->query.dns64_ttl = rdataset->base_ttl; #else
client->query.dns64_ttl = rdataset->ttl;
+#endif
query_releasename(client, );
dns_db_detachnode(db, );
rdataset = NULL;
diff -Nur bind-9.9.9-P2/config.h.in bind-9.9.9-P2-ttl/config.h.in
--- bind-9.9.9-P2/config.h.in   2016-07-14 08:54:33.0 +0900
+++ bind-9.9.9-P2-ttl/config.h.in   2016-07-27 08:35:55.669404673 +0900
@@ -159,6 +159,9 @@
 /* Define to enable the "filter--on-v4" option. */  #undef 

RE: a question about denied queries

[Darcy Kevin (FCA)]

Most likely, it has to do with recursion settings, yes, but indirectly. When 
recursion is not honored for a client, the next thing that named does is check 
whether the answer, or anything relevant to the answer, is in cache. But access 
to the cache, these days, defaults to being as restrictive as allow-recursion, 
so that permissions check fails too, and the end result is a "query (cached) 
denied" message in the logs.

The defaults are rather convoluted, but, according to the ARM:

allow-recursion. Specifies which hosts are allowed to make recursive 
queries through this server. If allow-recursion is not set then 
allow-query-cache is used if set, otherwise allow-query is used if set, 
otherwise the default (localnets; localhost;) is used.

allow-query-cache. Specifies which hosts are allowed to get answers 
from the cache. If allow-query-cache is not set then allow-recursion is used if 
set, otherwise allow-query is used if set unless recursion no; is set in which 
case none; is used, otherwise the default (localnets; localhost;) is used.


- Kevin



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Andreas 
Meyer
Sent: Thursday, August 04, 2016 1:04 PM
To: bind-users@lists.isc.org
Subject: a question about denied queries

Hello!

When I see this in the log, does this mean it is because the server does not 
allow recursion?

Aug  4 18:52:19 bitmachine1 named[26142]: client 127.0.0.1#52733 
(c303.cloudmark.com): query (cache) 'c303.cloudmark.com/A/IN' denied Aug  4 
18:56:08 bitmachine1 named[26142]: client 127.0.0.1#32773 
(113.36.207.103.in-addr.arpa): query (cache) 
'113.36.207.103.in-addr.arpa/PTR/IN' denied Aug  4 18:57:29 bitmachine1 
named[26142]: client 127.0.0.1#41550 (229.109.212.81.in-addr.arpa): query 
(cache) '229.109.212.81.in-addr.arpa/PTR/IN' denied Aug  4 18:57:29 bitmachine1 
named[26142]: client 127.0.0.1#45968 
(81.212.109.229.static.turktelekom.com.tr): query (cache) 
'81.212.109.229.static.turktelekom.com.tr/A/IN' denied Aug  4 18:57:30 
bitmachine1 named[26142]: client 127.0.0.1#46290 (229.109.212.81.in-addr.arpa): 
query (cache) '229.109.212.81.in-addr.arpa/PTR/IN' denied Aug  4 18:57:30 
bitmachine1 named[26142]: client 127.0.0.1#34166 
(81.212.109.229.static.turktelekom.com.tr): query (cache) 
'81.212.109.229.static.turktelekom.com.tr/A/IN' denied

Sorry, but it is a long time gone I have dealt with named.

  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: NXDOMAIN but still get it...

[Darcy Kevin (FCA)]

nslookup sucks.

What’s most likely happening is:

· On your initial query, some sort of transient error is occurring 
while trying to resolve centos.mirror.iweb.ca, e.g. a timeout, a misconfigured 
server returning SERVFAIL, a delegated server not being authoritative, etc.

· nslookup fails that query, then, behind the scenes (and unbeknownst 
to you) it starts searchlisting, e.g. looking up 
centos.mirror.iweb.ca.example.com. This results, as one might expect, in an 
NXDOMAIN

· nslookup (mis)reports NXDOMAIN as the result of the overall lookup

You can turn on “-debug” to nslookup to see if this is what’s really happening.

Or, dump nslookup altogether and use a real DNS troubleshooting tool like “dig”.


- Kevin



From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Bernard 
Fay
Sent: Wednesday, August 03, 2016 3:32 PM
To: bind-users@lists.isc.org
Subject: NXDOMAIN but still get it...

[ ~]# nslookup centos.mirror.iweb.ca
Server:172.21.241.18
Address:172.21.241.18#53

** server can't find centos.mirror.iweb.ca: 
NXDOMAIN



But ...



[ ~]$ nslookup iweb.ca
Server:172.21.241.18
Address:172.21.241.18#53

Non-authoritative answer:
Name:iweb.ca
Address: 174.142.1.18

[ ~]$ nslookup mirror.iweb.ca
Server:172.21.241.18
Address:172.21.241.18#53

Non-authoritative answer:
Name:mirror.iweb.ca
Address: 192.175.120.177

[ ~]$ nslookup centos.mirror.iweb.ca
Server:172.21.241.18
Address:172.21.241.18#53

Non-authoritative answer:
Name:centos.mirror.iweb.ca
Address: 192.175.120.169


What am I missing?  There is definitely something I do not understand.

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

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

RE: named and use of resolv.conf? - how to "learn" this

[Darcy Kevin (FCA)]

Is it really necessary to document everything that *isn't* true? That could 
fill volumes...

named is the thing that resolves stuff; /etc/resolv.conf tells processes whom 
to talk to if they want to resolve stuff. Put those things together, why would 
named need /etc/resolv.conf? To talk to *itself*?


- Kevin



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Spumonti Spumonti
Sent: Tuesday, August 02, 2016 12:26 PM
To: bind-users@lists.isc.org
Subject: named and use of resolv.conf? - how to "learn" this

(I've done several searches for this first but the general nature of some of 
these terms returned way too many non-relevant responses)

I was recently told that named does not use resolv.conf when resolving names. 
This was not something I was aware of but at this point I accept that. The 
system in question is an authoritative only server, no recursion enabled, that 
for some zones it hosts, lists secondary name servers in other organizations 
(in other words these name servers are in zones NOT hosted on this server)

My real question is: where is this documented? I've read DNS books and scoured 
different sites but couldn't find anything stating this was how named behaved. 
Maybe I just suck at searching for things or was using imprecise terms.
___
Please visit https://lists.isc.org/mailman/listinfo/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: Multiple AD domains

[Darcy Kevin (FCA)]

You could remove the GSS-TSIG dependency by using a non-Microsoft-based DHCP 
server and having it update DNS instead of the clients updating themselves.

It just so happens that the same consortium that maintains BIND (reference 
implementation of DNS) also maintains the reference implementation for DHCP…

I realize (from personal experience) that sweeping changes to an enterprise’s 
DHCP infrastructure can be, depending on size/complexity/diversity of the 
environment in question, much easier said than done – updating 
relays/”helpers”, firewall rules, failover/latency considerations, etc. But you 
might want to consider your long-term strategic goals. If you co-locate your 
DNS and DHCP on the same servers, for instance, you position yourself well for 
an eventual evolution to an appliance-based DNS/DHCP approach (e.g. Infoblox or 
its competitors).



- Kevin

[FCA_Pantone_email]
--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com

From: Vinícius Ferrão [mailto:fer...@if.ufrj.br]
Sent: Thursday, July 28, 2016 10:03 AM
To: Darcy Kevin (FCA)
Cc: bind-users@lists.isc.org
Subject: Re: Multiple AD domains

I agree with using BIND as the default DNS server even on Active Directory 
environments. Windows DNS on 2012 R2 is still very bad and lacks basic features 
like disabling external recursion. This should change on Server 2016 but I will 
stay with BIND.

Another thing that I would like to add to this thread is about completely 
ditching Windows DNS and use BIND as the master zone for AD. The default 
procedure is just creating the AD sub zone on BIND as master and allowing IP 
updates during the installation of AD. Since IP based updates are insecure, 
GSS-TSIG is used with Kerberos after the AD install. This is how we roll on our 
University.

But we are a facing a similar issue. We would like to have a single DNS 
managing two distinct (and without trusts) AD domains. Using IP based updates 
would work as expected with the two different zones, but we are screwed with 
the Kerberos Tickets and the keytabs. Since BIND does not allow multiple 
keytabs I really don't know what to do. If someone have an idea to solve this I 
will be very grateful.

Thanks in advance,
V.

Sent from my iPhone

On Jul 27, 2016, at 16:34, Darcy Kevin (FCA) 
<kevin.da...@fcagroup.com<mailto:kevin.da...@fcagroup.com>> wrote:
My preference? Have all your clients use BIND to resolve DNS (this gives access 
to more advanced features like sortlisting, good query logging, 
blacklisting/redirection through the RPZ mechanism, Anycast, etc.). Set up the 
BIND instances as slaves for the AD zones, and have the AD folks add the BIND 
instances to the apex NS records so that the DCs will trigger fast replication 
to BIND via the NOTIFY extension to the protocol.

I’d never let a regular PC client use Microsoft DNS for resolving DNS. Perish 
the thought!

Note that this approach, if implemented simply, doesn’t scale to large numbers 
of BIND instances (because you don’t want to add dozens or hundreds of apex NS 
records to the zone). Beyond a certain threshold, you’d want to set up a 
multi-level slaving/NOTIFY hierarchy on the BIND side…



- Kevin




--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com<mailto:kevin.da...@fcagroup.com>

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jeff 
Sadowski
Sent: Wednesday, July 27, 2016 3:00 PM
To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: Re: Multiple AD domains

should I setup 192.168.1.1 as slaves to these two domains would that fix it?

On Wed, Jul 27, 2016 at 12:56 PM, Jeff Sadowski 
<jeff.sadow...@gmail.com<mailto:jeff.sadow...@gmail.com>> wrote:
On the samba mailing list they described setting up the DC as the NS and 
forward to another machine for more rules.
This will work fine for one domain. Now lets say I have 2 domains.

If I setup forwarders like so on 192.168.1.1

zone "domainA" IN { type forward; forward only; forwarders { 192.168.2.1; }; };
zone "domainB" IN { type forward; forward only; forwarders { 192.168.3.1; }; };

It w

RE: Multiple AD domains

[Darcy Kevin (FCA)]

Yes, I did misread the original post; thanks for clarifying.

But, the gist of the question seemed to be about mitigating the effects of 
caching, for dynamically-changing data. At a high level, whether the zones are 
AD zones or not, whether the “master” is BIND or Microsoft DNS, doesn’t have a 
whole lot of bearing on that challenge. As should be obvious from what I 
proposed, I prefer the slaving+NOTIFY approach over setting up fragile 
forwarding arrangements.

The other sledgehammer approach, of course, is to set the TTLs really low, but 
that can have a disastrous effect on performance/capacity, according to how 
frequently the dynamically-changing names are being queried. Of course, no 
amount of named.conf tweaking will help to mitigate the effects of caching that 
occurs on the clients themselves (e.g. “nscd” on some *nix platforms, Windows 
resolver cache for Windows). The only standards-based solution for that is to 
lower the TTLs. (Non-standards-based solutions include ugly stuff like running 
a script on every client to flush the cache every minute, ugh). But, as always, 
lowering TTLs, should be done, if at all, with one’s eyes open to the 
performance/capacity impact.



- Kevin



[FCA_Pantone_email]
--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com

From: Chris Buxton [mailto:cli...@buxtonfamily.us]
Sent: Thursday, July 28, 2016 12:52 PM
To: Darcy Kevin (FCA)
Cc: bind-users@lists.isc.org
Subject: Re: Multiple AD domains

The OP's question was about setting up BIND, not MS DNS, related to using 
Samba, not Windows, as the domain controller.

Regards,
Chris

Sent from my iPhone

On Jul 27, 2016, at 12:36 PM, Darcy Kevin (FCA) 
<kevin.da...@fcagroup.com<mailto:kevin.da...@fcagroup.com>> wrote:
My preference? Have all your clients use BIND to resolve DNS (this gives access 
to more advanced features like sortlisting, good query logging, 
blacklisting/redirection through the RPZ mechanism, Anycast, etc.). Set up the 
BIND instances as slaves for the AD zones, and have the AD folks add the BIND 
instances to the apex NS records so that the DCs will trigger fast replication 
to BIND via the NOTIFY extension to the protocol.

I’d never let a regular PC client use Microsoft DNS for resolving DNS. Perish 
the thought!

Note that this approach, if implemented simply, doesn’t scale to large numbers 
of BIND instances (because you don’t want to add dozens or hundreds of apex NS 
records to the zone). Beyond a certain threshold, you’d want to set up a 
multi-level slaving/NOTIFY hierarchy on the BIND side…



- Kevin




--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com<mailto:kevin.da...@fcagroup.com>

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jeff 
Sadowski
Sent: Wednesday, July 27, 2016 3:00 PM
To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: Re: Multiple AD domains

should I setup 192.168.1.1 as slaves to these two domains would that fix it?

On Wed, Jul 27, 2016 at 12:56 PM, Jeff Sadowski 
<jeff.sadow...@gmail.com<mailto:jeff.sadow...@gmail.com>> wrote:
On the samba mailing list they described setting up the DC as the NS and 
forward to another machine for more rules.
This will work fine for one domain. Now lets say I have 2 domains.

If I setup forwarders like so on 192.168.1.1

zone "domainA" IN { type forward; forward only; forwarders { 192.168.2.1; }; };
zone "domainB" IN { type forward; forward only; forwarders { 192.168.3.1; }; };

It will cache entries for each domain and if a computer gets a different 
address for dhcp it will update on the domain's DNS but the dns on 192.168.1.1 
will have a cached entry untill it expires.

192.168.2.1 and 192.168.3.1 are setup to forward all other zones than their 
domain names to 192.168.1.1

if I have DNS server set for all machines in domainA to 192.168.2.1 all 
machines on domainA see any DNS changes to domainA imediately machines on 
domainB are cached and can take time to clear out.
And
if I have DNS server set for all machines in domainB to 192.168.3.1 all 
machines on domainB see an

RE: Multiple AD domains

[Darcy Kevin (FCA)]

My preference? Have all your clients use BIND to resolve DNS (this gives access 
to more advanced features like sortlisting, good query logging, 
blacklisting/redirection through the RPZ mechanism, Anycast, etc.). Set up the 
BIND instances as slaves for the AD zones, and have the AD folks add the BIND 
instances to the apex NS records so that the DCs will trigger fast replication 
to BIND via the NOTIFY extension to the protocol.

I’d never let a regular PC client use Microsoft DNS for resolving DNS. Perish 
the thought!

Note that this approach, if implemented simply, doesn’t scale to large numbers 
of BIND instances (because you don’t want to add dozens or hundreds of apex NS 
records to the zone). Beyond a certain threshold, you’d want to set up a 
multi-level slaving/NOTIFY hierarchy on the BIND side…



- Kevin



[FCA_Pantone_email]
--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jeff 
Sadowski
Sent: Wednesday, July 27, 2016 3:00 PM
To: bind-users@lists.isc.org
Subject: Re: Multiple AD domains

should I setup 192.168.1.1 as slaves to these two domains would that fix it?

On Wed, Jul 27, 2016 at 12:56 PM, Jeff Sadowski 
> wrote:
On the samba mailing list they described setting up the DC as the NS and 
forward to another machine for more rules.
This will work fine for one domain. Now lets say I have 2 domains.

If I setup forwarders like so on 192.168.1.1

zone "domainA" IN { type forward; forward only; forwarders { 192.168.2.1; }; };
zone "domainB" IN { type forward; forward only; forwarders { 192.168.3.1; }; };

It will cache entries for each domain and if a computer gets a different 
address for dhcp it will update on the domain's DNS but the dns on 192.168.1.1 
will have a cached entry untill it expires.

192.168.2.1 and 192.168.3.1 are setup to forward all other zones than their 
domain names to 192.168.1.1

if I have DNS server set for all machines in domainA to 192.168.2.1 all 
machines on domainA see any DNS changes to domainA imediately machines on 
domainB are cached and can take time to clear out.
And
if I have DNS server set for all machines in domainB to 192.168.3.1 all 
machines on domainB see any DNS changes to domainB imediately machines on 
domainA are cached and can take time to clear out.

What is the best way to resolve this issue?

___
Please visit https://lists.isc.org/mailman/listinfo/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: Sending extra info in bind dns query packet

[Darcy Kevin (FCA)]

Sachin,
I strongly suggest that you consider other methods to 
accomplish what you’re trying to achieve. You seem to have latched onto one 
particular method to reach your goal – modifying the contents of the DNS 
request and/or response packets – but this amounts to changing the DNS 
protocol. There is no BIND configuration “tweak” to accomplish it – you’d have 
to hack on code (probably the code for both the client and server sides). This 
is a significant undertaking, and if you’ve never hacked on BIND code before, 
prepare yourself for a steep learning curve.

If all you’re trying to do – as someone surmised in another post – is control 
client access to resources, then it should be possible to leverage existing 
non-DNS technologies and resources for this (firewalls, proxies, etc. 
configured with appropriate ACLs), or, as also suggested, RPZ. Why reinvent the 
wheel?



- Kevin

[FCA_Pantone_email]
--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Sachin 
Patil
Sent: Thursday, July 14, 2016 7:56 AM
To: Jan-Piet Mens
Cc: bind-users@lists.isc.org
Subject: Re: Sending extra info in bind dns query packet

I have searched through the list and found discussion about standard practice 
not to add it.
I did not find any post which gives clear idea on how to add the custom 
additional section record in dns query packet.

On Thu, Jul 14, 2016 at 5:04 PM, Jan-Piet Mens 
> wrote:
I did not get this... am I posting this to wrong mailing list?

This has been discussed several times on this list within the past few weeks.  
You should check the archives.

-JP

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

[Darcy Kevin (FCA)]

I think what the kids would say is "client PCAP or it didn't happen".

Now, get off my lawn... :-)

- Kevin


-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of John W. Blue
Sent: Thursday, June 16, 2016 11:58 PM
To: Phil Mayers; Daniel Stirnimann; bind-users@lists.isc.org
Subject: RE: Issues resolving outlook.office365.com

>These were being blamed on "the network".

Nothing can be blamed on the network without a client pcap.  Otherwise it is 
just a bunch of hand waving and hot air.  Show me the money.

;)

John
___
Please visit https://lists.isc.org/mailman/listinfo/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: Append a Hard-coded Text Tuple into Additional Section of "dig" Feature

[Darcy Kevin (FCA)]

My understanding is that the "extra" stuff wouldn't have any signature at all. 
Wouldn't that break DNSSEC if the rest of the response had signatures? Or does 
the DNSSEC-validation algorithm support "hybrid" responses like that?

- Kevin


-Original Message-
From: Tony Finch [mailto:d...@dotat.at] 
Sent: Thursday, June 16, 2016 7:09 AM
To: Darcy Kevin (FCA)
Cc: bind-users@lists.isc.org
Subject: RE: Append a Hard-coded Text Tuple into Additional Section of "dig" 
Feature

Darcy Kevin (FCA) <kevin.da...@fcagroup.com> wrote:
>
> It'll also, irrespective of caching, break DNSSEC.

No, extra stuff in the additional section should not break DNSSEC because the 
signatures are per-RRset not per-message.

Tony.
--
f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode 
Tyne, West Dogger: Variable 3 or 4, becoming northerly or northwesterly 5 or 6. 
Slight becoming moderate. Rain or showers, fog patches. Moderate or good, 
occasionally very poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

RE: Append a Hard-coded Text Tuple into Additional Section of "dig" Feature

[Darcy Kevin (FCA)]

That's not really consistent with the DNS standards, and will break if you have 
intermediate caching servers. Why? Because of this clause from RFC 2181:

Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and
data from the authority section of a non-authoritative answer, should
not be cached in such a way that they would ever be returned as
answers to a received query.

It'll also, irrespective of caching, break DNSSEC.

What information are you trying to "piggyback" on responses to regular queries? 
If it's a point-to-point thing, then create your own experimental record type, 
or EDNS option (you already indicated you were willing to do modifications of 
the BIND code and/or client-resolver code) in order to provide a "channel" for 
this data between the client and its closest resolver. If it's an end-to-end 
thing, understand that the authoritative nameservers "own" one end of that 
transaction, and any attempts to manipulate the flow via an intermediate 
device, reduces the integrity and trustworthiness of the data, making it look 
like forgery, and possibly to the point where it gets rejected.



- Kevin


From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jun Xiang X Tee
Sent: Wednesday, June 15, 2016 2:43 PM
To: bind-users@lists.isc.org
Subject: Append a Hard-coded Text Tuple into Additional Section of "dig" Feature


Dear members,



  This is my first time posting a question to the mailing list. I am not sure 
whether I should post my technical question to this list or not. If it is not, 
I apologize for any inconvenience caused.



  When I query for "google.com", the additional section returned is:


  ;; ADDITIONAL SECTION:
  ns1.google.com. 200487  IN  A   216.239.32.10
  ns2.google.com. 197774  IN  A   216.239.34.10
  ns3.google.com. 246981  IN  A   216.239.36.10
  ns4.google.com. 193728  IN  A   216.239.38.10

  I wish to append a hard-coded text tuple into end of the section. An example 
after the change is:

  ;; ADDITIONAL SECTION:
  ns1.google.com. 200487  IN  A   216.239.32.10
  ns2.google.com. 197774  IN  A   216.239.34.10
  ns3.google.com. 246981  IN  A   216.239.36.10
  ns4.google.com. 193728  IN  A   216.239.38.10
  google.com  123456  IN TXT   "some information that I 
want to include"

  I have searched through the code base for several days, but do not find a 
good place to start with. Any suggestion? I am currently examining "resolver.c" 
and "lookup.c" files. Thanks!

Regards,
Jun Xiang Tee

___
Please visit https://lists.isc.org/mailman/listinfo/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: also-notify and nsupdate doesnt work

[Darcy Kevin (FCA)]

Right. also-notify (on a master) versus allow-notify (on a slave). Different 
use cases.

- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Barry Margolin
Sent: Monday, May 02, 2016 5:08 PM
To: comp-protocols-dns-b...@isc.org
Subject: Re: also-notify and nsupdate doesnt work

In article <mailman.688.1462221733.73610.bind-us...@lists.isc.org>,
 "Darcy Kevin (FCA)" <kevin.da...@fcagroup.com> wrote:

> Apologies if this has already been asked, but are you sending these 
> NOTIFYs from a master which is _not_ in the "masters" clause of the 
> nameserver which is receiving it? That's precisely the use case for 
> "allow-notify"...

The use case for also-notify is when you have slave servers that aren't in the 
NS records of the zone. Otherwise, those slaves won't update until the Refresh 
timer goes off.

--
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: also-notify and nsupdate doesnt work

[Darcy Kevin (FCA)]

Apologies if this has already been asked, but are you sending these NOTIFYs 
from a master which is _not_ in the "masters" clause of the nameserver which is 
receiving it? That's precisely the use case for "allow-notify"...

- Kevin


-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of jo...@hasig.de
Sent: Monday, May 02, 2016 10:31 AM
To: Alan Clegg; Matthew Pounsett
Cc: bind-users@lists.isc.org
Subject: Re: also-notify and nsupdate doesnt work

hi,

 > There's nothing in this part of the configuration that links key usage to  > 
 > the zone.

sure. the * is.
and the update works great.
the serial counts up,
the update is taken,
the slave is motified and updated.

the only thing is, that the "also-notify" servers get no notify.
(if i do an rndc update abc.net on a hidden slave, the transfer is taken 
correct.).

jonny

___
Please visit https://lists.isc.org/mailman/listinfo/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: when i check resolver.log just now , i found some error info about AAAA ( ipv6)

[Darcy Kevin (FCA)]

I don't know about other GSLBs, but Cisco GSSes could be made to respond 
relatively sanely, with some careful configuration. We had to set up a "shadow" 
version of each GSLB-delegated subzone on BIND, and the GSSes would proxy all 
queries they couldn't handle themselves to/from this "shadow" version. The 
_piece_de_resistance_ is to add an obscure wildcard entry in each zone so that 
all non-apex proxied queries get a NODATA response. This is to inhibit 
inappropriate NXDOMAIN responses when the name is defined in the GSS, but the 
type is not handled, e.g. MX, TXT,  or whatever. Such inappropriate 
NXDOMAIN queries generate negative cache entries for the name, which can then 
interfere with the A queries. Not a perfect solution, but it got us by until we 
could migrate off that horrible platform.


- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Barry Margolin
Sent: Wednesday, April 13, 2016 4:45 PM
To: comp-protocols-dns-b...@isc.org
Subject: Re: when i check resolver.log just now , i found some error info about 
 ( ipv6)

In article <mailman.548.1460561615.73610.bind-us...@lists.isc.org>,
 "Darcy Kevin (FCA)" <kevin.da...@fcagroup.com> wrote:

> Really, there's no excuse, in this day and age, for a DNS-serving 
> device -- even a load-balancer pretending to be a nameserver -- to 
> botch its responses to  queries.

Load balancers routinely botch requests for any type other than the specific 
type they're programmed to balance. There's never been an excuse for it in the 
first place (how hard would it have been for them to return NOERROR?), so 
there's no reason to expect them to treat  any differently from other types 
that they don't know about.

-- 
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: when i check resolver.log just now , i found some error info about AAAA ( ipv6)

[Darcy Kevin (FCA)]

To be clear, "turning off" IPv6 in named (via the -4 flag or other means), 
doesn't mean named won't try to resolve any  records, especially if one of 
your (presumably IPv6-enabled) clients requests them. So, even with IPv6 
"turned off", if there are nameservers on the Internet that -- for whatever 
reason -- have trouble resolving  records, you'll see errors in the logs 
when you try to resolve  records from those nameservers.

Really, there's no excuse, in this day and age, for a DNS-serving device -- 
even a load-balancer pretending to be a nameserver -- to botch its responses to 
 queries.

For that matter, if your clients are enabled for IPv6, and you have good IPv6 
connectivity to the Internet, especially in the APAC region where IPv6 is, I 
hear, ubiquitous (and yes, I did verify that all of the IP addresses in your 
email were assigned to Chinese ISPs/telcos), why are you turning off IPv6 on 
your nameserver? Embrace it.


- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark Andrews
Sent: Wednesday, April 13, 2016 12:33 AM
To: johnzeng
Cc: bind-us...@isc.org
Subject: Re: when i check resolver.log just now , i found some error info about 
 ( ipv6)


Just another broken nameserver that doesn't handle  queries correctly.  It 
answers authoritatively for dlb.g5.letvlb.com/A but returns a referral for 
dlb.g5.letvlb.com/ with unrelated additional records.

Mark

% dig dlb.g5.letvlb.com @106.38.226.245

; <<>> DiG 9.11.0a1 <<>> dlb.g5.letvlb.com @106.38.226.245 ;; global options: 
+cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61581 ;; flags: qr aa rd; 
QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion 
requested but not available

;; QUESTION SECTION:
;dlb.g5.letvlb.com. IN  A

;; ANSWER SECTION:
dlb.g5.letvlb.com.  600 IN  A   123.59.122.228

;; Query time: 359 msec
;; SERVER: 106.38.226.245#53(106.38.226.245) ;; WHEN: Wed Apr 13 14:16:20 EST 
2016 ;; MSG SIZE  rcvd: 68

% dig dlb.g5.letvlb.com @106.38.226.245 

; <<>> DiG 9.11.0a1 <<>> dlb.g5.letvlb.com @106.38.226.245  ;; global 
options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1 ;; flags: qr aa rd; 
QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; WARNING: recursion 
requested but not available

;; QUESTION SECTION:
;dlb.g5.letvlb.com. IN  

;; AUTHORITY SECTION:
dlb.g5.letvlb.com.  600 IN  NS  ns1.letvlb.com.
dlb.g5.letvlb.com.  600 IN  NS  ns2.letvlb.com.
dlb.g5.letvlb.com.  600 IN  NS  ns3.letvlb.com.

;; ADDITIONAL SECTION:
au.ns1.letvlb.com.  600 IN  A   111.206.208.224
au.ns2.letvlb.com.  600 IN  A   106.38.226.245
au.ns3.letvlb.com.  600 IN  A   117.121.2.237

;; Query time: 492 msec
;; SERVER: 106.38.226.245#53(106.38.226.245) ;; WHEN: Wed Apr 13 14:16:25 EST 
2016 ;; MSG SIZE  rcvd: 269

% 


In message <570dc310.1060...@yahoo.com>, johnzeng writes:
> 
> Hello Dear Sir :
> 
> when i check resolver.log just now , i found some error info about 
>  ( ipv6)
> 
> although i search some helpful info from ask.com , but i can't find 
> the config file , maybe the reason is i compiled via source file ( 
> ./configure --prefix=/mydic ).
> 
> Whether i need build the config file ?
> 
> 
> 
> This of course won't stop bind from blindly trying to use ipv6 though, 
> so you also need to alter |/etc/default/bind9| like so:
> 
> |# run resolvconf? 
> RESOLVCONF=yes
> # startup options for the server
> OPTIONS="-4 -u bind"
> |
> 
> 
> 
> 
> 13-Apr-2016 11:49:11.858 DNS format error from 106.38.226.245#53 
> resolving dlb.g5.letvlb.com/ for client 127.0.0.1#53325:
> non-improving referral
> 13-Apr-2016 11:49:11.898 DNS format error from 111.206.208.224#53 
> resolving dlb.g5.letvlb.com/ for client 127.0.0.1#53325:
> non-improving referral
> 13-Apr-2016 11:49:11.939 DNS format error from 117.121.2.237#53 
> resolving dlb.g5.letvlb.com/ for client 127.0.0.1#53325:
> non-improving referral
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
> unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

RE: Configuring different TTLs in multiple RRs for the same domain name, TYPE, and CLASS

[Darcy Kevin (FCA)]

This is deliberately forbidden by standard. See RFC 2181, Section 5.2 ("TTLs of 
RRs in an RRSet")

Why would you want to do this?


- Kevin


From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ben Bridges
Sent: Thursday, March 24, 2016 10:48 AM
To: bind-users@lists.isc.org
Subject: Configuring different TTLs in multiple RRs for the same domain name, 
TYPE, and CLASS

Greetings.

Is it possible in BIND to configure multiple resource records for the same 
domain name, TYPE, and CLASS with different TTL values?  For example:

Test-txt.example.com 300IN   TXT"Test 300"
Test-txt.example.com 400IN   TXT"Test 400"
Test-txt.example.com 500IN   TXT"Test 500"
Test-txt.example.com 600IN   TXT"Test 600"
Test-txt.example.com 700IN   TXT"Test 700"

I tried it, and BIND set the TTL for all five records to 300 (or more 
specifically, the TTL of the first one of the RRs in the file).  I looked for a 
BIND directive in the manual to change this behavior but could find no obvious 
candidate.

Thanks,

Ben Bridges
Springfield, MO

___
Please visit https://lists.isc.org/mailman/listinfo/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: Can bind be configured to not drop RR's from the cache when the upstream DNS server is unresponsive

[Darcy Kevin (FCA)]

Would they be receptive to letting you slave the zone? At least then you’d have 
the whole EXPIRE time before the names stopped resolving.

If they’re concerned about security, then the transfers could be locked down by 
source IP address, or, if their software supports it, TSIG key.

One of the downsides of slaving, of course, is that changes might take a while 
to replicate, unless NOTIFY is set up.


- Kevin

[FCA_Pantone_email]
--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com

From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ron
Sent: Friday, March 18, 2016 4:46 AM
To: G.W. Haywood
Cc: bind-users@lists.isc.org
Subject: Re: Can bind be configured to not drop RR's from the cache when the 
upstream DNS server is unresponsive



On Fri, Mar 18, 2016 at 12:12 AM, G.W. Haywood 
> wrote:
Hi there,

On Thu, 17 Mar 2016, Ron wrote:
... in this case it's a supplier who is unable to keeps his DNS servers
working, and we just want to keep the connectivity.

I'd just put something in /etc/hosts and send myself an email every
month or so to remind me I'd done that.


This is what we're currently using, but it has the downside of not picking up 
ip address changes.

Ron



--

73,
Ged.



___
Please visit https://lists.isc.org/mailman/listinfo/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: Can bind be configured to not drop RR's from the cache when the upstream DNS server is unresponsive

[Darcy Kevin (FCA)]

By “upstream” I assume you’re talking about forwarders. If your forwarders are 
flakey, have you ever considered simply *not*forwarding*? That would seem to be 
a better, structural solution to your problem, than holding DNS data beyond its 
cache-expiration time (a really BAD idea).



- Kevin
[FCA_Pantone_email]
--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com

From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ron
Sent: Thursday, March 17, 2016 7:37 AM
To: bind-users@lists.isc.org
Subject: Can bind be configured to not drop RR's from the cache when the 
upstream DNS server is unresponsive

Hi,

subject says all. Read manpages, could not find this in the FAQ's.
Hope this is possible. If not does anyone know of other name servers
that offer this option?

Thanks,
Ron Arts


___
Please visit https://lists.isc.org/mailman/listinfo/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: Can bind be configured to not drop RR's from the cache when the upstream DNS server is unresponsive

[Darcy Kevin (FCA)]

Using DNS records beyond the owner-published TTL is risky business. You can’t 
even know if the same legal entity is providing the content or services 
previously published at that address/endpoint, and this uncertainty raises 
security and/or liability concerns.



- Kevin


From: Ron [mailto:ron.a...@gmail.com]
Sent: Thursday, March 17, 2016 11:46 AM
To: Darcy Kevin (FCA)
Cc: bind-users@lists.isc.org
Subject: Re: Can bind be configured to not drop RR's from the cache when the 
upstream DNS server is unresponsive

I did not mean forwarders, but I had a case where the authoritative name 
servers for a domain were down
for an extended period of time, exceeding the ttl for their records. I was 
curious if I could tell my DNS servers
to serve these records for longer than the registered ttl. And I wanted to 
automate that.

But I'm afraid that's not gonna fly.

Ron



On Thu, Mar 17, 2016 at 4:27 PM, Darcy Kevin (FCA) 
<kevin.da...@fcagroup.com<mailto:kevin.da...@fcagroup.com>> wrote:
By “upstream” I assume you’re talking about forwarders. If your forwarders are 
flakey, have you ever considered simply *not*forwarding*? That would seem to be 
a better, structural solution to your problem, than holding DNS data beyond its 
cache-expiration time (a really BAD idea).



- Kevin
[FCA_Pantone_email]
--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601<tel:%2B1%20%28248%29%20838-6601>
Mobile: +1 (810) 397-0103<tel:%2B1%20%28810%29%20397-0103>
Email: kevin.da...@fcagroup.com<mailto:kevin.da...@fcagroup.com>

From: bind-users-boun...@lists.isc.org<mailto:bind-users-boun...@lists.isc.org> 
[mailto:bind-users-boun...@lists.isc.org<mailto:bind-users-boun...@lists.isc.org>]
 On Behalf Of Ron
Sent: Thursday, March 17, 2016 7:37 AM
To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: Can bind be configured to not drop RR's from the cache when the 
upstream DNS server is unresponsive

Hi,

subject says all. Read manpages, could not find this in the FAQ's.
Hope this is possible. If not does anyone know of other name servers
that offer this option?

Thanks,
Ron Arts



___
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: Can bind be configured to not drop RR's from the cache when the upstream DNS server is unresponsive

[Darcy Kevin (FCA)]

So, they’re not the least bit embarrassed by their abject inability to provide 
reliable authoritative nameservice, eh?

In my experience, partners who have egg on their faces because they’ve recently 
caused major outages, tend to be more willing than usual to co-operate on ways 
to prevent further outages, and replicating zone data *is* the classic way to 
enhance its availability.

(And hopefully you understand that slaving the zone doesn’t require your 
nameservers to be published for them, although if you’re a “stealth slave” you 
might want to make special arrangements for NOTIFY, as I touched on in my 
previous message).


- Kevin

[FCA_Pantone_email]
--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com

From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ron
Sent: Friday, March 18, 2016 4:41 PM
To: bind-users@lists.isc.org
Subject: Re: Can bind be configured to not drop RR's from the cache when the 
upstream DNS server is unresponsive

Slave the zone? Oh, run secondary. Fat chance.

Ron

On Fri, Mar 18, 2016 at 5:03 PM, Darcy Kevin (FCA) 
<kevin.da...@fcagroup.com<mailto:kevin.da...@fcagroup.com>> wrote:
Would they be receptive to letting you slave the zone? At least then you’d have 
the whole EXPIRE time before the names stopped resolving.

If they’re concerned about security, then the transfers could be locked down by 
source IP address, or, if their software supports it, TSIG key.

One of the downsides of slaving, of course, is that changes might take a while 
to replicate, unless NOTIFY is set up.


- Kevin

[FCA_Pantone_email]
--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601<tel:%2B1%20%28248%29%20838-6601>
Mobile: +1 (810) 397-0103<tel:%2B1%20%28810%29%20397-0103>
Email: kevin.da...@fcagroup.com<mailto:kevin.da...@fcagroup.com>

From: bind-users-boun...@lists.isc.org<mailto:bind-users-boun...@lists.isc.org> 
[mailto:bind-users-boun...@lists.isc.org<mailto:bind-users-boun...@lists.isc.org>]
 On Behalf Of Ron
Sent: Friday, March 18, 2016 4:46 AM
To: G.W. Haywood
Cc: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: Re: Can bind be configured to not drop RR's from the cache when the 
upstream DNS server is unresponsive



On Fri, Mar 18, 2016 at 12:12 AM, G.W. Haywood 
<b...@jubileegroup.co.uk<mailto:b...@jubileegroup.co.uk>> wrote:
Hi there,

On Thu, 17 Mar 2016, Ron wrote:
... in this case it's a supplier who is unable to keeps his DNS servers
working, and we just want to keep the connectivity.

I'd just put something in /etc/hosts and send myself an email every
month or so to remind me I'd done that.


This is what we're currently using, but it has the downside of not picking up 
ip address changes.

Ron



--

73,
Ged.



___
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<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: forward only single zone

[Darcy Kevin (FCA)]

Don't turn your DNS and/or network infrastructures into pretzels trying to get 
this "forwarding" or "(reverse) proxying" to work. Ultimately, I expect you'll 
end up maintaining the records of interest in both an internal and an external 
version of the subzone. Then the only question becomes to what extent you can 
automate the "sync".


- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Oto BREZINA
Sent: Friday, March 04, 2016 6:09 PM
To: bind-users@lists.isc.org
Subject: forward only single zone

I got successfuly set schizophrenic bind based DNS. It is version 9.9.5 running 
on Ubuntu .

I got local zones :
 serving internal side.
 public zones master and slaves (server in same way for internal and 
externals clients)

I need to create one subzone of public zone which is served by another server. 
This can not be transfered. Server is located on LAN.
Is there way to set this? I tried to set views, but with no luck.

my setting right now is like:

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

 include "local zones";
 include "public zones";
 include "slave zones";
};

view "public" {
 allow-query { any; };
 match-clients { any; };
 recursion no;

 include "public zones"; // contains example.com with clue to same 
server
 include "slave zones";
};

I need to add

zone "calc.example.com" {
 type forward;
 forward only;
 forwarders { local_machine; };
 };

adding it to local wont let external client to get access, but works from 
internals adding it to public, does not help, it returns only clues; forward 
only wont word as recursion is no, adding another view public2 seems have no 
affect.

I'm aware it is not recomented setup, but even I would run separate local and 
public server, I have still no idea how have not open DNS but forward single 
zone.

Please advise.

Oto
___
Please visit https://lists.isc.org/mailman/listinfo/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: what does "max-ncache-ttl 0;" mean?

[Darcy Kevin (FCA)]

I wouldn't be so quick to assume that.

Nota bene this part of the ARM:

"Integers may take values 0 <= value <= 18446744073709551615, though certain 
parameters (such as max-journal-size) may use a more limited range within these 
extremes. In most cases, setting a value to 0 does not literally mean zero; it 
means 'undefined"' or 'as big as possible', depending on the context. See the 
explanations of particular parameters that use size_spec for details on how 
they interpret its use."

So, it might actually mean "as big as possible".

Consult the source code to be sure.
- Kevin


--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601 
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Tony Finch
Sent: Wednesday, March 02, 2016 8:29 AM
To: MURTARI, JOHN
Cc: bind-users@lists.isc.org
Subject: Re: what does "max-ncache-ttl 0;" mean? 

MURTARI, JOHN  wrote:
>
> So far, all the postings I've seen just echo what he already said (and 
> knows).  The question is - what happens when you set it to ZERO?
>
> I'm wondering myself - anyone have a real answer?

The code says zero means zero, so in effect it would disable negative cacheing.

Tony.
--
f.anthony.n.finch    http://dotat.at/ Thames, Dover, Wight: West 
veering northwest 7 to severe gale 9, decreasing 4 or 5 later. Rough or very 
rough, becoming moderate or rough later. Squally showers. Good, occasionally 
poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

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

RE: Interesting behavior with wildcard domains

[Darcy Kevin (FCA)]

See “empty non-terminal” in https://www.rfc-editor.org/rfc/rfc4592.txt.


- Kevin

[FCA_Pantone_email]
--
Kevin Darcy
NAFTA Information Security Projects

FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA

Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com

From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Noel Butler
Sent: Tuesday, February 23, 2016 6:19 PM
To: bind-users@lists.isc.org
Subject: Re: Interesting behavior with wildcard domains


On 24/02/2016 09:13, Mathew Ian Eis wrote:
Hi BIND,

I've encountered (quite by accident) an interesting behavior in BIND with 
wildcard domains:

The relevant configuration is a zone; e.g. bar.com, with what I'll call a 
"second level" wildcard host, e.g. *.foo.bar.com A 10.10.10.5 in that zone. (as 
opposed to what might be considered the more usual wildcard host record of 
*.bar.com).

buz.foo.bar.com returns A 10.10.10.5 as expected.

However, a query for foo.bar.com returns NOERR with zero results, when I would 
expect a NXDOMAIN.

Anyone know if the NOERR with zero results is the expected / correct behavior?

Thanks in advance,

Mathew Eis
Northern Arizona University
Information Technology Services


It's expected, since its a *  "." foo...
you are asking for anything thast dot foo, your not asking for foo


--
If you have the urge to reply to all rather than reply to list, you best first 
read  http://members.ausics.net/qwerty/


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

[Darcy Kevin (FCA)]

Let's be transparent here: reverse lookups are not a formal requirement, and, 
if I'm not mistaken, not even officially published as a Best Practice. Many 
folks don't bother with them.

Having said that, they are *very* useful, and I insist on them wherever 
possible.

If an organization decides to go with reverse mappings, one thing they should 
decide is how to handle reverse-lookup "ambiguities". By that, I mean, if you 
have NameA.example.com resolving to an address and NameB.example.com resolving 
to the same address, then where should the reverse mapping point? 
NameA.example.com or NameB.example.com? You can't really have *both*, since 
that's not the way reverse-resolution works (you can define both RRs in the 
RRset, but clients only see one of them, so what's the point?). It's tempting 
to say that NameA.example.com must be an alias for NameB.example.com or 
_vice_versa_, but aliases aren't always possible -- consider if both 
NameA.example.com and NameB.example.com are delegated subzones. The apex of a 
zone can't be an alias. So, this is a business decision that needs to be made. 
One possible rule is that ambiguities are simply *forbidden*, i.e. we disallow 
pointing a name directly at an IP address which is already mapped to a 
different n
 ame -- it has to be an alias, or it can't be created at all. But then you have 
to sell that to your customers, end-users, partners, etc. and that might not be 
an easy pill to swallow. This "ambiguity" decision is not a showstopper, just a 
stop along the journey. Lastly, I'll point out that if you (as we do) have a 
DNS maintenance system which automatically keeps the forward and reverse 
records in sync, then it needs to be aware of, and handle, whatever decision 
has been made in terms of reverse-record ambiguity. Our homegrown system 
handles this in a very inflexible, embedded way, as per decisions we made years 
ago. But a commercial product should be flexible enough to handle a wide 
variety of choices.


- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark Andrews
Sent: Monday, February 22, 2016 9:32 PM
To: David Li
Cc: BIND Users
Subject: Re: A Zone Transfer Question


I've yet to see a system that doesn't do reverse lookups automatically.
Lots of tools do it so, yes, you should be configuring the nameserver to return 
PTR records.

Mark

In message 
, David Li writes:
> Hi Mark,
> 
> Thanks for the explanation!
> 
> At this time all my stuff are internal to the data center so I just 
> added an option to listen to the IPv4 only. This seems to have made 
> these error messages gone away.
> 
> I do have another question:  If I don't need to do reverse lookup, do 
> I still need PTR records? In other words, is there any downside if I 
> don't have PTR records in my zone files?
> 
> David
> 
> 
> 
> 
> 
> On Mon, Feb 22, 2016 at 4:04 PM, Mark Andrews  wrote:
> >
> > This is named trying to talk to nameservers over IPv6 and being told 
> > by the OS that they are unreachable.
> >
> > At this point in time you should be yelling at your ISP to supply 
> > you with IPv6 connectivity if they aren't already as the world ran 
> > out of IPv4 addresses years ago and the network is only running 
> > because ISP's that don't have enough addresses are sharing them 
> > between multiple customers which is costing everyone in one way or 
> > another.
> >
> > If your ISP is offering you IPv6 you may need to update your CPE 
> > router to one which supports IPv6.
> >
> > There is no valid excuse for a ISP not supplying IPv6 in 2016.  They 
> > have had over a decade to plan for how to deliver IPv6 to you.
> >
> > Mark
> >
> >
> > In message  com>
> > , David Li writes:
> >> Barry and others:
> >>
> >> Thanks for the help!
> >> It's my bad that the slave zone's subnet range was missing from 
> >> allow-query. I also added the slave IP explicitly to the 
> >> allow-transfer option. Now it's seems to be working.
> >>
> >>
> >> Another issue that I haven't quite figured out is the errors in the 
> >> syslog. I have no idea where these are coming from:
> >>
> >>
> >>
> >> Feb 22 15:27:33 dli-centos7 named[2170]: error (network 
> >> unreachable) resolving 'node2/A/IN': 2001:503:c27::2:30#53 Feb 22 
> >> 15:27:33 dli-centos7 named[2170]: error (network unreachable) 
> >> resolving 'node2/A/IN': 2001:7fd::1#53 Feb 22 15:27:33 dli-centos7 
> >> named[2170]: error (network unreachable) resolving './NS/IN': 
> >> 2001:500:1::803f:235#53 Feb 22 15:27:33 dli-centos7 named[2170]: 
> >> error (network unreachable) resolving './NS/IN': 
> >> 2001:503:c27::2:30#53 Feb 22 15:27:33 dli-centos7 named[2170]: 
> >> error (network unreachable) resolving './NS/IN': 

RE: A Zone Transfer Question

[Darcy Kevin (FCA)]

Look at your "allow-query". It appears your master isn't letting your slave 
query it. Query access is a prerequisite for zone-refresh transactions.

- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of David Li
Sent: Friday, February 19, 2016 7:09 PM
To: John W. Blue
Cc: BIND Users
Subject: Re: A Zone Transfer Question

Hi John,

Well, I was wrong about the log. I did find some info about why zone transfer 
failed. On one server running zone rack1.com, I see:

Feb 19 16:04:27 dli-centos7 named[13882]: client 10.4.3.101#20745
(rack1.com): query 'rack1.com/SOA/IN' denied Feb 19 16:04:27 dli-centos7 
named[13882]: client 10.4.3.101#52612
(rack1.com): transfer of 'rack1.com/IN': IXFR ended

Any idea why it's denied?

David

On Fri, Feb 19, 2016 at 11:19 AM, John W. Blue  wrote:
> "kick off" as in update the zone and not by using dig.
>
> John
>
> Sent from Nine
>
> From: "John W. Blue" 
> Sent: Feb 19, 2016 1:17 PM
> To: David Li
>
> Cc: BIND Users
> Subject: Re: A Zone Transfer Question
>
> Nothing in the logs, eg?  Well so much for getting an easy resolution.  
> :D
>
> If you trust your conf files and logs are clean, I personally next to 
> turn to tcpdump.  You really need to know what (if anything) is being 
> placed on the wire.  Something like this should get you started:
>
> tcpdump -i eth0 -n port domain
>
> Kick off a transfer and see what happens.
>
> John
>
> Sent from Nine
>
> From: David Li 
> Sent: Feb 19, 2016 1:04 PM
> To: John W. Blue
> Cc: BIND Users
> Subject: Re: A Zone Transfer Question
>
> Hi John,
>
> Nothing in the /var/log/messages indicates transfer problems. In fact 
> I don't think the transfer ever started by itself for some reason 
> until I manually used "dig" to initiate.
>
> David
>
> On Fri, Feb 19, 2016 at 9:00 AM, John W. Blue  wrote:
>> Hello David,
>>
>> You can get started by checking your log files to see if named is 
>> complaining about anything it might not like that is preventing the 
>> transfer.
>>
>> John
>>
>> Sent from Nine
>>
>> From: David Li 
>> Sent: Feb 19, 2016 10:46 AM
>> To: BIND Users
>> Subject: A Zone Transfer Question
>>
>> This is my first time to try master slave configuration. Here is a
>> brief description:
>>
>> I have two Centos 7.1 VMs - each is configured for a zone. VM1 is the
>> master for zone1 and slave for zone2. VM2 is master for zone2 and
>> slave for zone1. Both zones uses DNS Dynamic Update from DHCP 
>> servers on the same VM
>> to update the A records in their zone files. No DNSSEC configured.
>>
>>
>> To start, everything seems to be working fine. I have one host in each
>> zone and they can resolve each other fine.
>>
>> Now I add a new host to zone1 and its sequence number has been bumped
>> up. I read that when the zone1 file changes, it will automatically
>> notify its slave zone (ie. zone2) to start a zone transfer after 15
>> min. This never happened. Then I restarted named on VM2 and hoped it
>> would pull the new zone1 file. This didn't happened either.
>> Eventually I have to either restart the VM2 or use dig to start the
>> zone transfer.
>>
>> Can anyone spot anything obviously wrong here? Do I need to post my
>> zone file and named.conf?
>>
>>
>> Thanks.
>>
>> David
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/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 Zone Transfer Question

[Darcy Kevin (FCA)]

As pointed out previously, however, with a 1-minute REFRESH, NOTIFY is pretty 
much a non-issue.

- Kevin

-Original Message-
From: Darcy Kevin (FCA) 
Sent: Friday, February 19, 2016 4:25 PM
To: BIND Users
Subject: RE: A Zone Transfer Question

How do you suppose named knows where to send the NOTIFY messages? It's only 
"automatic" to the nameservers listed in the NS records of the zone. But you 
didn't list your slave, did you? I seem to recall there was only 1 NS record, 
and that's presumably the master...


- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of David Li
Sent: Friday, February 19, 2016 3:56 PM
To: John Miller
Cc: BIND Users
Subject: Re: A Zone Transfer Question

Hi John,

Sorry I missed the options. I attached them below.

I didn't have allow-transfer, allow-notify and also-notify. I only have 
allow-query. I read somewhere that NOTIFY is automatic for all slave zones. Is 
this the problem?



For VM1 named.conf

options {

directory "/var/named";
allow-query {
   10.4.1/24;
   127.0.0.1;
};

};

For VM2 named.conf

options {

directory "/var/named";
allow-query {
   10.4.3/24;
   127.0.0.1;
};

};

On Fri, Feb 19, 2016 at 12:33 PM, John Miller <johnm...@brandeis.edu> wrote:
> Hi David,
>
> Something I'm not seeing in your config is an options {} block that 
> lays out your defaults for allow-transfer, allow-notify, also-notify, 
> etc.  Those are important things to know when it comes to 
> troubleshooting zone transfer issues.  Unless you've got a specific 
> reason for not doing so, please include your entire named.conf file - 
> it'll make life much easier.
>
> And if you've solved things already - ignore!
>
> John
>
> On Fri, Feb 19, 2016 at 2:01 PM, David Li <dlipub...@gmail.com> wrote:
>> Hi John,
>>
>> Here are the files. They are all internal zones without any 
>> references to external name servers.
>>
>> VM1:
>> 
>>
>> named.conf:
>> -
>>
>> #
>> # master (on VM1)
>> #
>> zone "rack1.com" {
>> type master;
>> file "/var/named/db.rack1.com";
>> allow-update { key rndc-key-rack1; }; # For DHCP dynamic update 
>> };
>>
>> #
>> # slave (on VM2)
>> #
>> zone "rack3.com" {
>> type slave;
>> file "/var/named/bak.rack3.com";
>> masters { 10.4.3.101; }; #VM3 named IP };
>>
>>
>> zone file:
>> /var/named/db.rack1.com
>> -
>>
>> $ORIGIN .
>> $TTL 907200 ; 1 week 3 days 12 hours
>> rack1.com   IN SOA  dnsserver1.rack1.com. admin.rack1.com. (
>> 8  ; serial
>> 60 ; refresh (1 minute)
>> 60 ; retry (1 minute)
>> 604800 ; expire (1 week)
>> 3600   ; minimum (1 hour)
>> )
>> NS  dnsserver1.rack1.com.
>> $ORIGIN rack1.com.
>> dnsserver1  A   10.4.1.101
>>
>> $TTL 3600   ; 1 hour
>> node1   A   10.4.1.11
>> TXT "007ddd47ea6ddcd890312de89e37bde496"
>> node2   A   10.4.1.12
>> TXT "316a8d5e65fbd9f853df6d90ad1f24ecac"
>> node3   A   10.4.1.13
>> TXT "009da8179478f9169cb47965e53d19f134"
>>
>> On VM2
>> ===
>>
>>
>>
>> named.conf file
>> ---
>>
>>
>>
>>
>> #
>> # Master
>> #
>> zone "rack3.com" {
>> type master;
>> file "/var/named/db.rack3.com";
>> allow-update { key rndc-key-rack3; }; # For DHCP update };
>>
>>
>> #
>> # Slave
>> #
>> zone "rack1.com" {
>> type slave;
>> file "/var/named/bak.rack1.com";
>> masters { 10.4.1.101; }; # VM1 named IP address
>> };
>>
>>
>>
>>
>> zone file:
>> --
>>
>> $ORIGIN .
>> $TTL 907200 ; 1 week 3 days 12 hours
>> rack3.com   IN SOA  dnsserver3.rack3.com. admin.rack3.com. (
>> 2  ; seria

RE: A Zone Transfer Question

[Darcy Kevin (FCA)]

How do you suppose named knows where to send the NOTIFY messages? It's only 
"automatic" to the nameservers listed in the NS records of the zone. But you 
didn't list your slave, did you? I seem to recall there was only 1 NS record, 
and that's presumably the master...


- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of David Li
Sent: Friday, February 19, 2016 3:56 PM
To: John Miller
Cc: BIND Users
Subject: Re: A Zone Transfer Question

Hi John,

Sorry I missed the options. I attached them below.

I didn't have allow-transfer, allow-notify and also-notify. I only have 
allow-query. I read somewhere that NOTIFY is automatic for all slave zones. Is 
this the problem?



For VM1 named.conf

options {

directory "/var/named";
allow-query {
   10.4.1/24;
   127.0.0.1;
};

};

For VM2 named.conf

options {

directory "/var/named";
allow-query {
   10.4.3/24;
   127.0.0.1;
};

};

On Fri, Feb 19, 2016 at 12:33 PM, John Miller  wrote:
> Hi David,
>
> Something I'm not seeing in your config is an options {} block that 
> lays out your defaults for allow-transfer, allow-notify, also-notify, 
> etc.  Those are important things to know when it comes to 
> troubleshooting zone transfer issues.  Unless you've got a specific 
> reason for not doing so, please include your entire named.conf file - 
> it'll make life much easier.
>
> And if you've solved things already - ignore!
>
> John
>
> On Fri, Feb 19, 2016 at 2:01 PM, David Li  wrote:
>> Hi John,
>>
>> Here are the files. They are all internal zones without any 
>> references to external name servers.
>>
>> VM1:
>> 
>>
>> named.conf:
>> -
>>
>> #
>> # master (on VM1)
>> #
>> zone "rack1.com" {
>> type master;
>> file "/var/named/db.rack1.com";
>> allow-update { key rndc-key-rack1; }; # For DHCP dynamic update 
>> };
>>
>> #
>> # slave (on VM2)
>> #
>> zone "rack3.com" {
>> type slave;
>> file "/var/named/bak.rack3.com";
>> masters { 10.4.3.101; }; #VM3 named IP };
>>
>>
>> zone file:
>> /var/named/db.rack1.com
>> -
>>
>> $ORIGIN .
>> $TTL 907200 ; 1 week 3 days 12 hours
>> rack1.com   IN SOA  dnsserver1.rack1.com. admin.rack1.com. (
>> 8  ; serial
>> 60 ; refresh (1 minute)
>> 60 ; retry (1 minute)
>> 604800 ; expire (1 week)
>> 3600   ; minimum (1 hour)
>> )
>> NS  dnsserver1.rack1.com.
>> $ORIGIN rack1.com.
>> dnsserver1  A   10.4.1.101
>>
>> $TTL 3600   ; 1 hour
>> node1   A   10.4.1.11
>> TXT "007ddd47ea6ddcd890312de89e37bde496"
>> node2   A   10.4.1.12
>> TXT "316a8d5e65fbd9f853df6d90ad1f24ecac"
>> node3   A   10.4.1.13
>> TXT "009da8179478f9169cb47965e53d19f134"
>>
>> On VM2
>> ===
>>
>>
>>
>> named.conf file
>> ---
>>
>>
>>
>>
>> #
>> # Master
>> #
>> zone "rack3.com" {
>> type master;
>> file "/var/named/db.rack3.com";
>> allow-update { key rndc-key-rack3; }; # For DHCP update
>> };
>>
>>
>> #
>> # Slave
>> #
>> zone "rack1.com" {
>> type slave;
>> file "/var/named/bak.rack1.com";
>> masters { 10.4.1.101; }; # VM1 named IP address
>> };
>>
>>
>>
>>
>> zone file:
>> --
>>
>> $ORIGIN .
>> $TTL 907200 ; 1 week 3 days 12 hours
>> rack3.com   IN SOA  dnsserver3.rack3.com. admin.rack3.com. (
>> 2  ; serial
>> 60  ; refresh ()
>> 60   ; retry ()
>> 604800 ; expire (1 week)
>> 3600   ; minimum (1 hour)
>> )
>> NS  dnsserver3.rack3.com.
>> $ORIGIN rack3.com.
>> dnsserver3  A   10.4.3.101
>> $TTL 3600   ; 1 hour
>> node1   A   10.4.3.11
>> TXT "001395d7d2a164c7efde811584bbc470b9"
>>
>>
___
Please visit https://lists.isc.org/mailman/listinfo/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 Zone Transfer Question

[Darcy Kevin (FCA)]

Guys,
REFRESH is set to 1 minute. That's not a long time to wait. Just do 
a packet capture and see if the slave is issuing zone-refresh queries regularly 
in the 30-second-to-1-minute range (it's randomized, of course, between 
REFRESH/2 and full REFRESH).

If the slave isn't issuing refreshes, then check whether the zone got loaded 
properly as a slave zone in the first place, and that the masters clause is set 
properly.

If the slave *is* issuing refreshes, is it getting a response? Are the refresh 
queries even showing up on the master side?

If the refresh queries are getting a response, but there's no AXFR/IXFR 
following subsequently, look in the log files for some sort of resource issue, 
e.g. concurrent zone transfers or something of that nature.


- Kevin

From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of John W. Blue
Sent: Friday, February 19, 2016 2:19 PM
To: David Li
Cc: BIND Users
Subject: Re: A Zone Transfer Question

"kick off" as in update the zone and not by using dig.

John

Sent from Nine

From: "John W. Blue" >
Sent: Feb 19, 2016 1:17 PM
To: David Li
Cc: BIND Users
Subject: Re: A Zone Transfer Question

Nothing in the logs, eg?  Well so much for getting an easy resolution.  :D

If you trust your conf files and logs are clean, I personally next to turn to 
tcpdump.  You really need to know what (if anything) is being placed on the 
wire.  Something like this should get you started:

tcpdump -i eth0 -n port domain

Kick off a transfer and see what happens.

John

Sent from Nine

From: David Li >
Sent: Feb 19, 2016 1:04 PM
To: John W. Blue
Cc: BIND Users
Subject: Re: A Zone Transfer Question

Hi John,

Nothing in the /var/log/messages indicates transfer problems. In fact
I don't think the transfer ever started by itself for some reason
until I manually used "dig" to initiate.

David

On Fri, Feb 19, 2016 at 9:00 AM, John W. Blue 
> wrote:
> Hello David,
>
> You can get started by checking your log files to see if named is
> complaining about anything it might not like that is preventing the
> transfer.
>
> John
>
> Sent from Nine
>
> From: David Li >
> Sent: Feb 19, 2016 10:46 AM
> To: BIND Users
> Subject: A Zone Transfer Question
>
> This is my first time to try master slave configuration. Here is a
> brief description:
>
> I have two Centos 7.1 VMs - each is configured for a zone. VM1 is the
> master for zone1 and slave for zone2. VM2 is master for zone2 and
> slave for zone1. Both zones uses DNS Dynamic Update from DHCP
> servers on the same VM
> to update the A records in their zone files. No DNSSEC configured.
>
>
> To start, everything seems to be working fine. I have one host in each
> zone and they can resolve each other fine.
>
> Now I add a new host to zone1 and its sequence number has been bumped
> up. I read that when the zone1 file changes, it will automatically
> notify its slave zone (ie. zone2) to start a zone transfer after 15
> min. This never happened. Then I restarted named on VM2 and hoped it
> would pull the new zone1 file. This didn't happened either.
> Eventually I have to either restart the VM2 or use dig to start the
> zone transfer.
>
> Can anyone spot anything obviously wrong here? Do I need to post my
> zone file and named.conf?
>
>
> Thanks.
>
> David
> ___
> Please visit https://lists.isc.org/mailman/listinfo/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: Tuning for lots of SERVFAIL responses

[Darcy Kevin (FCA)]

Ah, so "recursive-clients" is the quota of queries that require named to 
recurse to get the answer, right? I was going to respond with the same advice 
-- slave your internal zones -- but then I somehow convinced myself that 
"recursive-clients" was merely the quota of concurrent RD=1 queries that named 
would handle, thus slaving wouldn't help in a network-outage situation, since 
named would still drop any new RD=1 query whenever the quota was full.

I concur with the 10x recommendation, and also the advice about mail servers. 
My mail servers -- at least, the ones that run on Linux -- are configured with 
local caching resolvers, due to the high volume and wide variety of lookups 
they generate. And the typical OS-level caching mechanisms (nscd, etc.) don't 
usually help much, I don't believe, since many of the lookups are for MX 
records which, AFAICT, nscd and friends don't cache.


- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark Andrews
Sent: Thursday, February 18, 2016 4:08 PM
To: John Miller
Cc: Bind Users Mailing List
Subject: Re: Tuning for lots of SERVFAIL responses


In message 

RE: Zone hints for VPN environments

[Darcy Kevin (FCA)]

Note that there are additional considerations if there are any descendant 
(child, grandchild, etc.) zones of intra.example.net. If "type forward" is 
specified in the intra.example.net zone definition, and nothing defined below 
that, then recursive queries will continue to be sent, even for names in 
descendant zones, to whatever is defined as "forwarders" at that level in the 
hierarchy. That may or may not be optimal.

In contrast, "stub" or "static-stub" will query for names in descendant zones 
either by sending recursive queries to the global forwarders (if defined and 
not suppressed), or, if global forwarders are not defined, or they are 
suppressed, the iterative resolution algorithm will be used to obtain the 
answer, without using recursion, e.g. following the referral chain down from 
the closest-enclosing zone. This will _generally_ result in better performance 
and reliability, but is highly dependent on having "good" (reachable, fast, 
properly-configured) NS records published at each level of the hierarchy. Note 
that forwarding "suppression" can be effected via the idiosyncratic syntax 
"forwarders { };" in the zone definition.

Another poster suggested "type slave", i.e. replicating the zone contents via 
the standards-defined AXFR/IXFR features of the protocol. While I'm generally a 
big fan of zone replication, between different legal entities there is often a 
concern about unintentional information disclosure. Also, zone-transfer 
permission would have to be granted on the server side, and between BIND and 
Microsoft DNS, it can be tricky to work out a mutually-acceptable 
authentication method. On the plus side, replicating the zone provides 
performance and availability benefits, and replicated zone data is more 
resilient against forgery attacks. Please understand that if one opts to 
replicate the zone, one's nameserver doesn't have to be *published* for the 
zone, i.e. it can be a "stealth slave". It is a common misconception -- 
especially among Windows types -- that all nameservers holding zone data 
authoritatively need to be published as such. If the zone changes frequently, 
one should give some th
 ought to how quickly those changes replicate, and whether to set up NOTIFY. 
Note that "forwarding suppression" might need to be specified for a slave zone 
just as it would for a "stub"-type zone.

Whether "type forward", "type slave" or "type stub" is more appropriate, 
depends on one's architecture, namespace and security requirements. Within the 
2 different "stub" types -- "classic" stub _versus_ "static-stub" -- that's 
mostly a manageability/maintainability question (whether one wants the 
master/slave interaction to be dynamic, and subject to the 
zone-refresh-and-expiration mechanism, or just statically-maintained in one's 
named.conf), although the NAT consideration that Andreas pointed out is a valid 
one.


- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Tony Finch
Sent: Monday, February 15, 2016 5:58 AM
To: Andreas Meile
Cc: bind-users@lists.isc.org
Subject: Re: Zone hints for VPN environments

Andreas Meile  wrote:

> The question is: How can I place the ActiveDirectory DNS as forwarder 
> DNS server in such a way that it is responsible for a specific DNS zone only?

You very nearly have the right idea, but you are trying to use the wrong zone 
type. There are a few options that can work in your situation:

type stub - The "masters" you specify must be authoritative for the zone.
Your server fetches the NS records from the masters and resolves
names for the zone using these NS records. This is a bit like a
hint zone, except hints are only for the root zone.

type static-stub - You specify "server-addresses" or "server-names" which
must be authoritative for the zone. These servers are used
directly, ignoring the zone's NS records. This might work better
than a stub zone if your network disagrees with the zone contents
because of NAT.

type forward - You specify "forwarders" which must be recursive servers
that know how to resolve names in the zone.

There are more details about zone types in the ARM at
http://ftp.isc.org/isc/bind9/9.10.3-P3/doc/arm/Bv9ARM.ch06.html#id2595082

Tony.
--
f.anthony.n.finch    http://dotat.at/
Biscay: Northeast 6 to gale 8, decreasing 4 or 5 later. Very rough or high, 
becoming rough or very rough. Showers. Good, occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

RE: Resolver optimization of auth selection - Truth or Myth?

[Darcy Kevin (FCA)]

I suspect they changed the algorithm, in light of recent research findings 
about attackability. See 
http://www.cs.technion.ac.il/~gnakibly/papers/WOOT13.pdf



- Kevin


From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of MURTARI, JOHN
Sent: Monday, February 08, 2016 1:36 PM
To: bind-users@lists.isc.org
Subject: Resolver optimization of auth selection - Truth or Myth?

Folks,
Just trying to settle a question on BIND based resolver 
operation.  When given multiple authoritative servers for a zone, does it 
optimize selection based on auth server response times?  For example:

---
I'm located in Sydney, Australia and my ISP has a couple of 
BIND based resolvers also located there.  I'm trying to get to 
www.example.com and it happens to have three 
authoritative servers, ns{1,2,3}.example.com with a single unicast IP and 
located as follows:

ns1.example.com - Signapore,   ns2.example.com - Los Angeles,   
ns3.example.com - New York

We'll assume DNS round trip time (RTT) are proportional to 
distance from Sydney; also,  the fine folks at example.com have set a 10 minute 
TTL on all their resource records and have never heard of anycast IPs.   They 
are also very reliable, so we're not considering the effects of a 
non-responsive server.

So.do the BIND resolvers in Sydney begin to notice their 
quickest source of responses is ns1 and when cache data expires, do they go 
there first?  Or, are did the people at example.com waste money trying to 
locate one of their authoritative servers in Singapore to better serve their 
Australian visitors?
-

I did do a little searching on this and found what seemed to be 
a decent paper, no date, but covered up to BIND 9.8: 
http://irl.cs.ucla.edu/data/files/papers/res_ns_selection.pdf

If you take a look at sections 4.1 & 4.2 - they seem to say  
BIND 9.8 gets it a little backwards and starts to prefer higher latency servers?

Any clarification on this is welcome.
Thanks!

John




John Murtari - jm5...@att.com
Ciberspring
office: 315-944-0998
cell: 315-430-2702

___
Please visit https://lists.isc.org/mailman/listinfo/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: separation of authoritative and recursive functions on internal networks

[Darcy Kevin (FCA)]

Why not? Data obtained from the recursive function will never outrank 
authoritative data of a master or a slave. See the "Data Ranking" section of 
RFC 2181. AFAICT, it's been a *very* long time since BIND, or any other DNS 
implementation, has accidentally got those ranking rules wrong and given 
preference to cached data.

The main theoretical concern about mixing recursive and published-authoritative 
functions on the same nameserver instance, would be that the recursive 
functions -- which tend to be rather variable and unpredictable -- might take 
up too much resources and thus interfere with the published-authoritative 
functions of the same instance. But that's actually a reason to have *more* NS 
records (to spread out the load, and to provide sufficient failover capability 
in case one node gets overloaded, at any particular time), not an argument to 
leave nodes *out* of the NS records. Diversity is a good thing, and 
nameserver-selection failover tends to be very quick.

A better reason to limit the number of NS records is that, at a certain point, 
your Authoritative Section on DNS responses may -- if EDNS0 is not ubiquitous 
-- grow packet sizes to the point that they cause TCP retries. This is 
especially likely when slaving Active Directory zones, since AD's recommended 
practice is for *every* domain controller to run DNS, and the default behavior, 
at DC promotion time, is to register the DC in the NS records of the domain, if 
it's running DNS.

A much less likely reason for limiting the NS records of a zone is if one wants 
to "shape" the traffic flows of queries and (potentially) Dynamic Updates, 
because, say, some links are a lot more expensive than others (by "expensive" I 
mean in an economic sense, not in terms of latency, since the 
nameserver-selection algorithm already takes latency into account). But, given 
that DNS traffic tends to be a small fraction of overall traffic, this concern 
is not likely to be a factor.

RFC 2182 recommends 3 NSes per zone, but that RFC was written in 1997, and 
oriented towards Internet-facing nameservers, at a time when the Internet 
wasn't nearly as geographically-diverse as it is today. Around here, as a 
somewhat-large, geographically-diverse enterprise, we tend to have 8-ish NSes 
for our internal zones, plus or minus a few, depending on how "localized" the 
zone is. For the Internet-facing stuff, we have less NSes, but they're all VIPs 
of some kind, backed by multiple devices each. By implementing load-balancing, 
Anycast, or some combination of the two, it's possible to make a zone highly 
available without exploding the number of NS records published for it.


- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mathew Ian Eis
Sent: Friday, January 29, 2016 5:56 PM
To: Mark Andrews
Cc: bind-us...@isc.org
Subject: Re: separation of authoritative and recursive functions on internal 
networks

Howdy Mark,

Can you please clarify the best practice for this?

> Recursive servers (honouring RD=1) however can be authoritative for zones.

In this context of "authoritative", do you mean that they can be fully 
functional slaves and have a complete copy of the zone information?

I would imagine you would still not want such recursive servers to be truly 
authoritative (e.g. listed in the NS records for the zones), correct?

Thanks in advance,

Mathew Eis
Northern Arizona University
Information Technology Services
mathew@nau.edu
(928) 523-2960








-Original Message-
From:  on behalf of Mark Andrews 

Date: Monday, August 10, 2015 at 11:12 AM
To: Gary Carr 
Cc: "bind-us...@isc.org" 
Subject: Re: separation of authoritative and recursive functions on internal
networks

>
>Authoritative servers (listed in NS records) shouldn't be recursive.
>This prevents leakage of cache data.  This provide consistent answers.  
>The server also doesn't have to decide what type of answer to give 
>(recursive vs authoritative).  Glue doesn't get overridden by answers, 
>etc.
>
>Recurive servers (honouring RD=1) however can be authoritative for 
>zones.  This proves robustness in the presence of link failures.
>Faster than ttl expiry of local zone changes (provided that notify 
>messages are sent).
>
>Unfortunately this has become strict seperation lore which really 
>wasn't ever the intent.
>
>Mark
>--
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>___
>Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>unsubscribe from this list
>
>bind-users mailing list
>bind-users@lists.isc.org
>https://lists.isc.org/mailman/listinfo/bind-users

RE: dns search list

[Darcy Kevin (FCA)]

Suffix searching is a client function, there is no explicit support for it in 
BIND or any nameserver implementation.

The only incredibly ugly thing you could do in DNS to support shortname 
resolution is set up a "fake" root zone containing the names you need to 
resolve. But, you really don't want to go down that path. I consider it a 
responsibility of DNS admins to push back on any unreasonable 
shortname-resolution requests from their customers/end-users. There are *very* 
few things left in today's technology ecosystem that *require* shortname 
resolution. If it's just for _convenience_, then a management/political 
decision needs to be made, weighing the efficiency/scaling needs of the 
infrastructure, and the security/reliability risks of unexpected suffix 
matching, against the "convenience" arguments of those asking for shortname 
resolution.

DHCP supplies a single domain suffix (option 15) which Windows clients can use 
for suffixing (but understand first the interactions between 
Connection-specific Suffix, Primary Domain Suffix and Suffix Search List). That 
should be sufficient for any residual shortname-resolution needs. Note that you 
don't *have* to give the same option 15 value to everything in the same DHCP 
scope. If you have a sufficiently-advanced DHCP server, you could tailor that 
value according to, say, the "user class" set by the client and reported via 
DHCP (see RFC 3004). It might be possible to tailor it based on other 
parameters too (e.g. vendor class, RFC 3925), or combinations of parameters.



- Kevin

From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Julie Xu
Sent: Thursday, January 28, 2016 6:47 PM
To: bind-users@lists.isc.org
Subject: RE: dns search list

Hi


As I understand that dns search option 119 is not work with MS client.

But, I do need make a dns search list to ask MS client search a dns list. Could 
anyone advice me except group policy, do I have anyway to achive this point by 
change something in bind?

Any comments will be appreciated

Thanks in advance


Julie

___
Please visit https://lists.isc.org/mailman/listinfo/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 resolution failure on a caching server -- many '; pending-answer' records in the cache

[Darcy Kevin (FCA)]

NXDOMAIN is not a "failure" response. Are you *sure* you're getting NXDOMAIN? 
If you're using nslookup to test, be aware that it will do suffix searching by 
default, so if the original query, e.g. www.bbc.co.uk  fails, it'll quietly 
(unless debug-mode is in effect) start appending suffixes. Looking up those 
suffixed names, e.g. www.bbc.co.uk.example.com, mostly likely gets an NXDOMAIN, 
so nslookup reports NXDOMAIN as the overall result of the query. So, it's 
basically a misreporting of the error by nslookup. 

Note that only 1 of the records in your cache dump is actually relevant -- the 
CNAME from www.bbc.co.uk to www.bbc.net.uk -- and the others are for a 
different part of the namespaces (thdow.bbc.co.uk).

If you do an explicit query of the CNAME, when the problem is occurring, does 
it resolve? I would expect, even though the cache entry is marked 
"pending-answer", it will still resolve. But, without the target of the CNAME 
also resolving, the lookup as a whole cannot succeed.


- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
tpcb...@mklab.ph.rhul.ac.uk
Sent: Tuesday, January 26, 2016 8:02 PM
To: bind-users@lists.isc.org
Subject: Name resolution failure on a caching server -- many '; pending-answer' 
records in the cache

Dear All,
 I run a caching server on a section of the departmental LAN.
Occasionally network congestion results in timeouts & name resolution failures. 
 Lookups performed on name servers outside my LAN section fail with NXDOMAIN.  
Querying my name server for items not in its cache gets the same result.

My problem is that long after the congestion has subsided, queries to my name 
server still result in NXDOMAIN failure.  AFAICT this situation remains 
indefinitely, until the cache is flushed 'rndc flush' or the bind restarted.  
When it is in this state dumping the cache with 'rndc dumpdb' shows numerous 
entries like this,


; pending-additional
thdow.bbc.co.uk.76632   NS  ns3.bbc.net.uk.
76632   NS  ns4.bbc.co.uk.
76632   NS  ns4.bbc.net.uk.
76632   NS  ns3.bbc.co.uk.
; pending-answer
ns0.thdow.bbc.co.uk.2082\-  ;-$NXRRSET
; thdow.bbc.co.uk. SOA ns.bbc.co.uk. hostmaster.bbc.co.uk. 2015122100 1800 600 
864000 86400 ; pending-answer
76632   A   212.58.240.162
; pending-answer
www.bbc.co.uk.  30  CNAME   www.bbc.net.uk.
; glue


and attempts to lookup eg. www.bbc.co.uk result in NXDOMAIN.

Browsing the documentation I noticed the parameter 'max-ncache-ttl'
which is unset in my named.conf and apparently defaults to 3hours.
However the problem persists long after 3hours has elapsed following incidents 
of network congestion.

I could setup a cronjob to check name resolution on external domains and flush 
the cache when it fails?  I am assuming there must be better solution!  Should 
I set max-ncache-ttl to something fairly short in my named.conf and hope that 
the default value is for some reason actually
>> 3hours?

BTW I there a way to dump out all the parameters from a running named
-- just to see all their values ?


Any ideas on how to solve or further diagnose the problem?

Many thanks
Tom Crane

System details:
OS:Scientific Linux CERN SLC release 6.7 (Carbon) [NB: SLC is a derivative 
of RHEL]
BIND:  bind-9.8.2-0.37.rc1.el6_7.5.x86_64

Ps. I originally posted in Usenet NG comp.protocols.dns.bind but got no 
followups and then noticed all messages in that NG had this ML's fields 
'NNTP-Posting-Host: lists.isc.org' and 'X-Original-To: 
bind-users@lists.isc.org' etc. in their headers.  Is c.p.d.b actually a 
moderated group now or exclusively tied to this ML via a mail2news gateway?

-- 
Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill,
Egham, Surrey, TW20 0EX, England.
Email:  T dot Crane at rhul dot ac dot uk

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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/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: frequent queries to root servers

[Darcy Kevin (FCA)]

Well, when I queried the name livetileedge.dsx.mp.microsoft.com, I got a CNAME 
chain where all of the links in the chain had TTLs of 300 seconds or less:

livetileedge.dsx.mp.microsoft.com. 43 IN CNAME  
livetileedge.dsx.mp.microsoft.com.akadns.net.
livetileedge.dsx.mp.microsoft.com.akadns.net. 300 IN CNAME 
livetileedge.dsx.mp.microsoft.com.edgekey.net.
livetileedge.dsx.mp.microsoft.com.edgekey.net. 46 IN CNAME 
e1898.b.akamaiedge.net.
e1898.b.akamaiedge.net. 20  IN  A   23.201.56.85

Now, the Authority Section had NS records for b.akamaiedge.net, but that 
doesn't help mitigate future queries for {whatever}.microsoft.com, 
{whatever}.akadns.net or {whatever}.edgekey.net, so repeated queries of the 
same name will need to go back up to the roots again, whenever the TTLs expire 
(assuming nothing else queried names *directly* in those domains, or 
intermediate domains, through the same recursive resolver and thus populated 
relevant NS records).

Yet another reason why chained CNAMEs are bad. But, it's hard to argue with a 
successful company whose whole business model is based on chaining CNAMEs. Who 
ever knew that violating Internet standards and/or best practices could be so 
profitable?


- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of HONTVÁRI Levente
Sent: Tuesday, January 26, 2016 9:07 AM
To: bind-users@lists.isc.org
Subject: frequent queries to root servers

Hi All,

I assumed that the root servers are only queried a few times a week 
(corresponding to the number of top level domains). The logs show a different 
picture, Queries to the root servers are quite frequent. What am I missing?

I have attached a dnstop screen (local network traffic was filtered out), after 
running for about 2 hours. I also attached a log extract about a single query 
from 10.0.3.44 resolved by 10.0.3.48, which involves a query to the root 
servers. I notice that there is a DS record query before the root server query, 
but otherwise I do not see anything strange.

I have an almost stock Bind 9.9.5 resolver configuration on an Ubuntu server.

L.
___
Please visit https://lists.isc.org/mailman/listinfo/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: Overriding a single record with dynamic-dns

[Darcy Kevin (FCA)]

Well, the apex record of a zone can’t be an alias, and you can’t legally point 
an MX record to an alias as its target. So I don’t know if you’ll get much 
success, either way…

Can you move off the dynamic stuff to a subzone, e.g. dhcp.example.com? Then 
the main zone could be static, and that would give you more flexibility.

Generally speaking, you’ll want to split off your dynamic data anyway, since 
there’s so much “churn” associated with such zones. If dynamic and static 
entries co-exist in the same part of the namespace hierarchy, there’s also an 
increased possibility of collision.



- Kevin

From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of gnafou
Sent: Friday, January 22, 2016 3:03 AM
To: bind-users@lists.isc.org
Subject: RE: Overriding a single record with dynamic-dns

Hello

Thank you for your detailed answer ...

but, indeed i do need some of the dynamic dns data in the external view and 
yes, the mx is it the apex ..

Your answer makes me wonder  if i should be playing with cname aliases and 
build a separate 'static' zone with two views

Thanks again

Fred
___
Please visit https://lists.isc.org/mailman/listinfo/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: Overriding a single record with dynamic-dns

[Darcy Kevin (FCA)]

Addition of an MX record to a dynamically-updated zone can be accomplished 
multiple ways, but I’d recommend using nsupdate.

Responding differently to “internal” versus “external” queries implies views.

But, the burning questions that need to be answered are:
1) do you need those DHCP-driven records to be present in *both* views (i.e. 
internally and externally)? and
2) is the MX record you’re talking about the *apex* record of the zone (as 
opposed to something underneath the apex, like smtp.example.com)?

If the answer to both of those questions is “yes”, then I think you’re in for a 
bit of a challenge, since I don’t know that the DHCP server will be able to 
make *parallel* updates to *multiple* views. Things are much simpler if the 
zone is dynamic in one view (updated by DHCP), and static in the other.

If the MX record is something other than the apex, then this also makes things 
somewhat simpler, since you can delegate that particular name as a separate 
zone, static, and resolving differently internally and externally, and make the 
main zone, with all of those dynamically-updated records, able to resolve the 
same internally and externally (e.g. stub or slave between the views).



- Kevin

From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of gnafou
Sent: Thursday, January 21, 2016 11:27 AM
To: bind-users@lists.isc.org
Subject: Overriding a single record with dynamic-dns

Hello

I have a zone myzone.com where dynamic dns is active ( dhcp updates 
continuously the dns )

I need to respond differently for MX requests  such as :

MX for "internal"   queries  ismxinternal.myzone.com
MX for "internet"  queries   is   mxexternal.myzone.com



I cannot find out how to setup bind to achieve this  while keeping the dynamic 
dns in operation


Sincerely

Fred



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

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