Re: Introductory DNS Books

[John Miller]

On Wed, Aug 29, 2018 at 10:59 AM, Grant Taylor via bind-users
 wrote:
> On 08/29/2018 04:05 AM, John Miller wrote:
>>
>> Does anyone know of a good intro-level book that explains how DNS works
>> and gives an current overview of the different DNS servers out there?
>
>
> I'll argue that the basics have not changed.

I agree - the basics haven't changed: an A record is still an A
record; iterative queries are still iterative queries; etc.  But so
much has changed in the DNS world these days with all the different
cloud DNS providers, advances in RPZ, DNSSEC, etc. that a fresh
perspective wouldn't hurt anyone.  I realize I'm asking this of the
bind-users list, so answers will be somewhat BIND-specific, but folks
here are knowledgeable about DNS in general as well.

>
> Get a good foundation of the basics and then add new deltas / refinements on
> top of that.
>
> I see no reason not to start with DNS & BIND or Jan-Piet Mens' book.
>
> I've never looked at Pro DNS and BIND [1], but I frequently see it show up
> when I'm researching things.  Usually from zytrax's site [2].
>
> [1] http://www.netwidget.net/books/apress/dns/
> [2] http://www.zytrax.com/books/dns/ch7/view.html
>

Hmm... I've got the paper copy of this book, but the website covers
newer material.  I'll definitely advise folks to have a look there.

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

Introductory DNS Books

[John Miller]

Hi folks,

I have a couple of colleagues who are looking to learn more about DNS.
The 5th edition of Paul & Cricket's book used to be my go-to
reference, but it's more than 10 years out of date at this point, and
doesn't cover a lot of the new features of BIND.  Nor does it cover
alternatives to BIND, like PowerDNS, NSD, MS DNS, etc.  Jan-Piet Mens'
book did this, but again, it's pretty dated at this point.

Does anyone know of a good intro-level book that explains how DNS
works and gives an current overview of the different DNS servers out
there?

John
-- 
John Miller
Senior Systems Engineer
Brandeis University ITS
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Removing an NS server

[John Miller]

On Wed, Aug 8, 2018 at 9:10 AM, Bob Harold  wrote:
>
> On Tue, Aug 7, 2018 at 5:01 PM John Miller  wrote:
>>
>> Hal, we've done this before - it's not particularly hard, just takes a
>> bit for everyone to pick up the new set of NS records.  You just make
>> the change upstream and also remove the NS records that reference the
>> system.  It's kind of weird: during the interim, you'll have a running
>> nameserver that doesn't return itself in its NS records.  If the same
>> set of servers also serves your reverse zones, don't forget to update
>> ARIN as well as Educause.
>>
>> Educause sets their upstream TTLs to two days (ARIN's 1 day), but
>> people shouldn't be caching the referral, only your actual NS records.
>> If you're at all concerned, you can always set a low TTL ahead of time
>> on your NS records, so everyone will pull the updated records
>> relatively quickly once you make your changes.
>>
>> John
>>
>> On Tue, Aug 7, 2018 at 4:46 PM, King, Harold Clyde (Hal) 
>> wrote:
>> > I don't think I made my point. I need to pull/remove a DNS nameserver
>> > from my set of nameservers.
>> > My plan was to put the reference to it from our domain name provider.
>> > Then pull it from the list of NS records. I am not changing my SOA record.
>> > Just the nameserver. Did I make a mistake? Did you mean pull the NS reord
>> > for that server, then pull it from the name provider. I'll still have 4
>> > servers running the SOA, and I don't plan to stop the old nameserver until
>> > well after a week of running.
>> >
>> >
>> > --
>> > Hal King  - h...@utk.edu
>> > Systems Administrator
>> > Office of Information Technology
>> > Shared Systems Services
>
>
> If I remember correctly, setting my NS ttl lower than my parent caused a
> problem when one of my servers failed and I took it out of the NS record
> set.  I think it went something like this:
>
> resolver asks tld (before the change) and gets:
> example.com 2d NS dns1.example.com
> example.com 2d NS dns2.example.com
> example.com 2d NS dns3.example.com
>
> dns3 fails and I remove it from the NS records, both locally and at the
> parent TLD.
>
> Resolver talks to my servers (a few hours later, after the change) and gets:
> example.com 1h NS dns1.example.com
> example.com 1h NS dns2.example.com
>
> Resolver cache now has:
> example.com 1h NS dns1.example.com
> example.com 1h NS dns2.example.com
> example.com 2d NS dns3.example.com
>
> An hour later the two shorter NS records expire and the resolver is left
> with:
> example.com 2d NS dns3.example.com
>
> If dns3.example.com is down, the resolver will fail to reach my zone, and
> will not ask the TLD until that record expires.
>
> So I think the TTL on NS records needs to match the parent zone, whether I
> like that ttl or not.
>
> In your case, removing the NS records from both your zone and the parent
> zone, two days (or whatever the ttl) before you turn off the server, should
> be fine.
>
> --
> Bob Harold
>

Oh wow - I hadn't thought about that one, Bob: I was assuming that the
upstream records wouldn't be cached, but if they are, you're
absolutely right - zero fun trying to troubleshoot a problem like
that.

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

Re: Removing an NS server

[John Miller]

Hal, we've done this before - it's not particularly hard, just takes a
bit for everyone to pick up the new set of NS records.  You just make
the change upstream and also remove the NS records that reference the
system.  It's kind of weird: during the interim, you'll have a running
nameserver that doesn't return itself in its NS records.  If the same
set of servers also serves your reverse zones, don't forget to update
ARIN as well as Educause.

Educause sets their upstream TTLs to two days (ARIN's 1 day), but
people shouldn't be caching the referral, only your actual NS records.
If you're at all concerned, you can always set a low TTL ahead of time
on your NS records, so everyone will pull the updated records
relatively quickly once you make your changes.

John

On Tue, Aug 7, 2018 at 4:46 PM, King, Harold Clyde (Hal)  wrote:
> I don't think I made my point. I need to pull/remove a DNS nameserver from my 
> set of nameservers.
> My plan was to put the reference to it from our domain name provider. Then 
> pull it from the list of NS records. I am not changing my SOA record. Just 
> the nameserver. Did I make a mistake? Did you mean pull the NS reord for that 
> server, then pull it from the name provider. I'll still have 4 servers 
> running the SOA, and I don't plan to stop the old nameserver until well after 
> a week of running.
>
>
> --
> Hal King  - h...@utk.edu
> Systems Administrator
> Office of Information Technology
> Shared Systems Services
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: SERVFAIL and peak utilization

[John Miller]

Hi Alex,

What does your query volume look like on this server?  Depending on
volume, the BIND defaults for:

- clients-per-query
- max-clients-per-query
- recursive-clients
- tcp-clients

and others may not be set high enough.  Check pp. 106-108 in the
latest 9.11 manual for more details on each of these.

Of course, if you're only seeing SERVFAIL for a handful of domains,
then they may have some sort of delegation issue, or there might be a
network issue between your caching servers and them.

John


On Thu, Jul 26, 2018 at 1:07 PM, Alex  wrote:
> Hi,
>
> I have a bind-9.11.4 server on a fedora28 system and are frequently
> seeing SERVFAIL errors like this:
>
> 26-Jul-2018 12:54:04.255 query-errors: info: client @0x7f764314a5c0
> 127.0.0.1#50719 (223.178.102.199.cidr.bl.mcafee.com): query failed
> (SERVFAIL) for 223.178.102.199.cidr.bl.mcafee.com/IN/A at
> ../../../bin/named/query.c:4140
>
> I believe this happens more frequently at times of peak link
> utilization, but it also appears to happen during normal times.
>
> This is a local caching server I've set up but it also appears to
> exist on other systems that have been set up to be authoritative for
> our domain.
>
> How can I troubleshoot this further?
>
> Here is the named.conf for this caching server:
>
> acl "trusted" {
> { 127/8; };
> { 68.195.191.40/29; };
> { 192.168.1.0/24; };
> { 107.155.67.2/32; };
> };
>
> options {
> listen-on port 53 { 127.0.0.1; 68.195.191.45; };
> listen-on-v6 port 53 { none; };
> directory "/var/named";
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named.stats"; // _PATH_STATS
> memstatistics-file "/var/named/data/named.memstats";   // 
> _PATH_MEMSTATS
> allow-query { trusted; };
> recursion yes;
> zone-statistics yes;
>
> // dnssec-enable yes;
> // dnssec-validation yes;
> // dnssec-lookaside auto;
>
> dnssec-enable no;
> dnssec-validation no;
> dnssec-lookaside no;
>
> /* Path to ISC DLV key */
> bindkeys-file "/etc/named.iscdlv.key";
>
> managed-keys-directory "/var/named/dynamic";
>
> };
>
> logging {
> channel default_debug {
> file "data/named.run";
> severity dynamic;
> };
>
> // Record all queries to the box for now
> channel query_info {
>severity info;
>file "/var/log/named.query.log" versions 3 size 10m;
>print-time yes;
>print-category yes;
>  };
>
> // added for fail2ban support
> channel security_file {
>severity dynamic;
>file "/var/log/named.security.log" versions 3 size 30m;
>print-time yes;
>print-category yes;
> };
>
> channel b_debug {
> file "/var/log/named.debug.log" versions 2 size 10m;
> print-time yes;
> print-category yes;
> print-severity yes;
> severity dynamic;
> };
>
> // Send the security related messages to a separate file.
> channel audit_log {
> file "/var/log/named.audit.log" versions 4 size 10m;
> severity info;
> print-time yes;
> print-category yes;
> };
>
>
> category queries { query_info; };
> category default { b_debug; };
> category config { b_debug; };
> category security { security_file; };
> // category lame-servers { audit_log; };
> category lame-servers { null; };
>
> };
>
> zone "." IN {
> type hint;
> file "/var/named/named.ca";
> };
>
> zone "localhost.localdomain" IN {
> type master;
> file "named.localhost";
> allow-update { none; };
> };
>
> zone "localhost" IN {
> type master;
> file "named.localhost";
> allow-update { none; };
> };
>
> zone 
> "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa"
> IN {
> type master;
> file "named.loopback";
> allow-update { none; };
> };
>
> zone "1.0.0.127.in-addr.arpa" IN {
> type master;
> file "named.loopback";
> allow-update { none; };
> };
>
> zone "0.in-addr.arpa" IN {
> type master;
> file "named.empty";
> allow-update { none; };
> };
>
> include "/etc/named.root.key";
> include "/etc/rndc.key";
> ___
___
Please visit https://lists.isc.org/mailman/listinfo/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

[John Miller]

Hi Elias,

Generally not.  Unless .intra is a valid top-level-domain, and
company.intra is registered with the .intra registrars, your external
DNS will need to be different.  And in any case, you probably want
your public Internet presence to reflect your actual company name and
be in a TLD that people are expecting to see (.com if you're a
business, .org if a non-profit, country-based TLD depending on where
you're at, etc.).

John

On Tue, Jun 26, 2018 at 4:03 PM, Elias Pereira  wrote:
> Hello,
>
> My external DNS can be a subdomain of my root domain?
>
> Eg:
> root domain: company.intra
> external dns: named.company.intra
>
> --
> 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
>



-- 
John Miller
Senior Systems Engineer
Brandeis University ITS
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: extranet.aro.army.mil - not resolving

[John Miller]

Hi Con,

May I suggest running dig +trace extranet.aro.army.mil from your
nameserver?  That'll make the delegation process explicit and help you
troubleshoot a little better.  It could be that one of the three main
army.mil nameservers is unreachable by your ns for some reason
(routing being a likely culprit).

John

On Thu, May 31, 2018 at 5:29 PM, Con Wieland  wrote:
> and here they are but I don’t see anything indicating what the problem might 
> be
>
> 31-May-2018 13:56:01.150 queries: info: client 128.200.1.20#37203 
> (extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A +E 
> (128.200.1.201)
> 31-May-2018 13:56:01.151 resolver: debug 1: createfetch: 
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> 31-May-2018 13:56:06.153 queries: info: client 128.200.1.20#37203 
> (extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A +E 
> (128.200.1.201)
> 31-May-2018 13:56:06.153 resolver: debug 1: createfetch: 
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> 31-May-2018 13:56:11.158 queries: info: client 128.200.1.20#37203 
> (extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A +E 
> (128.200.1.201)
> 31-May-2018 13:56:11.158 query-errors: debug 1: client 128.200.1.20#37203 
> (extranet.aro.army.mil): view internal: query failed (SERVFAIL) for 
> extranet.aro.army.mil/IN/A at query.c:7215
> 31-May-2018 13:56:11.158 resolver: debug 1: createfetch: 
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> 31-May-2018 13:56:21.168 query-errors: debug 1: client 128.200.1.20#37203 
> (extranet.aro.army.mil): view internal: query failed (SERVFAIL) for 
> extranet.aro.army.mil/IN/A at query.c:7215
>
>> On May 31, 2018, at 12:51 PM, Reindl Harald  wrote:
>>
>>
>>
>> Am 31.05.2018 um 21:42 schrieb Con Wieland:
>>> agreed but why would my server not resolve it while others do?
>>
>> ask the logs of 128.200.1.201
>>
>> ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> extranet.aro.army.mil
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56491
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>> ;; SERVER: 128.200.1.201#53(128.200.1.201)
>>
>>>> On May 31, 2018, at 12:16 PM, Reindl Harald  wrote:
>>>>
>>>>
>>>>
>>>> Am 31.05.2018 um 21:09 schrieb Con Wieland:
>>>>> I have a nameserver that can not resolve extranet.aro.army.mil.
>>>>
>>>> terrible slow and insane config - fix it
>>>>
>>>> https://intodns.com/aro.army.mil
>>>>
>>>> ;; Query time: 1175 msec
>>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>>> ;; WHEN: Do Mai 31 21:12:26 CEST 2018
>>>> ;; MSG SIZE  rcvd: 247
>>>>
>>>> ;; Query time: 1109 msec
>>>> ;; SERVER: 8.8.8.8#53(8.8.8.8)
>>>> ;; WHEN: Do Mai 31 21:12:52 CEST 2018
>>>> ;; MSG SIZE  rcvd: 191
>>>>
>>>> ;; ANSWER SECTION:
>>>> aro.army.mil.   2022IN  NS  ns03.army.mil.
>>>> aro.army.mil.   2022IN  NS  ns02.army.mil.
>>>> aro.army.mil.   2022IN  NS  ns01.army.mil.
>>>>
>>>> ;; Query time: 163 msec
>>>> ;; SERVER: 192.82.113.7#53(192.82.113.7)
>>>> ;; WHEN: Do Mai 31 21:15:37 CEST 2018
>>>> ;; MSG SIZE  rcvd: 98
>>>> WarnSOA REFRESH WARNING: Your SOA REFRESH interval is: 900. 
>>>> That is
>>>> not so ok
>>>> WarnSOA RETRY   Your SOA RETRY value is: 90. That is NOT OK
>>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



-- 
John Miller
Senior Systems Engineer
Brandeis University ITS
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Use case for "." queries

[John Miller JR]

 Hello,
On bind recursive server I am seeing lots of queries for "." with type ANY.
Is there any use case which requires devices to send queries for "." with
type ANY ?

Appreciate your support.

Thanks
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

Odd behavior on a secondary server

[John Miller]

Hello there,

 

We are setting up a secondary server and seeing something that may be
normal, but I wanted to check. The time stamp on each zone file on the
secondary is changing with each refresh cycle, even if there are no changes
to the file.

 

Is this normal or am I missing something.

 

Thanks - John

 

-

John H. Miller

Asst. Dir. of CNS for Telecom

Muskingum University

Computer & Network Services

163 Stormont Street

New Concord, Ohio  43762

 

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

[John Miller]

Hi Anvar,

I see you have your named.conf file listed here; can you please paste
your named.rpz file as well?

John

On Wed, Jan 24, 2018 at 4:19 PM, Anvar Kuchkartaev via bind-users
 wrote:
> Hello,
>
> I am trying to update RPZ zone records dynamically using nsupdate. But
> unfortunately I am facing with NOTZONE option.
>
> nsupdate -k /etc/rndc.key < nsupdate.txt
>
> Outgoing update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  0
> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
> ;; ZONE SECTION:
> ;rpz.INSOA
>
> ;; UPDATE SECTION:
> 32.213.60.86.188.rpz-client-ip.60 INCNAME rpz-passtrhu.
>
> update failed: NOTZONE
>
>
> nsupdate.txt:
>
> server localhost
> zone rpz
> update add 32.213.60.86.188.rpz-client-ip.60CNAME rpz-passtrhu.
> show
> send
>
>
> my rpz zone:
>
> zone "rpz" IN {
> type master;
> file "named.rpz";
> allow-query { localhost; };
> update-policy {
> grant rndc-key zonesub ANY;
> };
> };
>
> Any help will be greatly appreciated,
>
___
Please visit https://lists.isc.org/mailman/listinfo/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: Email & PTR Issues

[John Miller]

Hi James,

Having a PTR record for your IP address is sort of a baseline standard
that e-mail providers use to tell whether you're a spammer or not:
your forward and reverse DNS records must match up.  More
specifically, the FQDN that you provide in your SMTP EHLO must match
your forward and reverse DNS records.

If your mail server is EHLOing as obrien-pifer.com, then you must have
a matching PTR record.  Doesn't look like you have one: the address
space belongs to your ISP:

212.108.in-addr.arpa.3600INSOAns1.swbell.net.
rm-hostmaster.ems.att.com. 21 10800 900 604800 7200

so you'll need to talk with them to resolve it.  If they don't support
PTR records, I'd suggest moving your mail server elsewhere: matching
DNS records is pretty much a requirement these days for running a mail
server.

John

On Tue, Nov 7, 2017 at 10:31 AM, James Pifer <j...@obrien-pifer.com> wrote:
> Hello. I'm looking for help with an issue I've been fighting for some time.
>
> Background:
> Running BIND 9.9.
> Forwarding UDP & TCP Port 53 through firewall.
>
> I have issues emailing to certain domains. I use my own mail server to
> deliver mail. It is currently not sending through SMTP Relay. The failure
> says that I have a missing PTR record. For example:
>
> host al-ip4-mx-vip2.prodigy.net[144.160.235.144]
> said: 550 5.7.1 Connections not accepted from servers without a valid
> sender domain.alph151 Fix reverse DNS for 108.212.144.25 (in reply to
> MAIL
> FROM command)
>
> If I do a test on mxtoolbox it also says I have the issue:
> https://mxtoolbox.com/SuperTool.aspx?action=smtp%3aobrien-pifer.com=toolpage#
>
> If I look at dnsstuff and do a test on Mail Server Test Center and run
> selected tests under the MX Dashboard it gives a DNS Mismatch.
>
> BUT, If I look at dnsstuff,com and do a reverse lookup test, that seems
> successful:
> http://www.dnsstuff.com/tools#reverseDns|type=ipv4&=108.212.144.25&=mail.obrien-pifer.com
>
> Also, from a pc somewhere else on the internet, if you change your DNS
> server to mine (or use nslookup) it resolves the reverse entry ok.
>
>>nslookup
>
>> server 108.212.144.25
> Default Server:  [108.212.144.25]
> Address:  108.212.144.25
>
>> 108.212.144.25
> Server:  [108.212.144.25]
> Address:  108.212.144.25
>
> Name:obrien-pifer.com
> Address:  108.212.144.25
>
>>
>
> If anyone has any helpful suggestions it is appreciated.
>
> I also tried moving my DNS to the provider I purchased my domain name from
> thinking that would be an easy fix. They don't support PTR records and
> actually had no clue what they even were.
>
> I've also tried configuring my mail servers to use ATT's SMTP Relay, but so
> far I've been unsuccessful getting it to send at all. The emails keep
> getting deferred. Obviously not an issue for anyone on this list. Just
> providing info.
>
> Thanks
> James
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: NOAA.GOV domain not working

[John Miller]

Hi Ricky,

Sounds like if things are timing out at the noaa.gov nameservers, then
that's where you need to start looking.  Try each nameserver that the
.gov nameservers give for noaa.gov and see if all of them are
unreachable, if just one's unreachable, if they're traceroute-able,
etc.  A lot of times, the problem isn't with DNS, per se, but with
general network connectivity between your nameservers and theirs.

FWIW, specifying @ with dig +trace really doesn't do much:
your machine is still going to follow the delegation records itself.

John

On Mon, Sep 18, 2017 at 10:40 AM, Levesque, Ricky (SNB)
<ricky.leves...@snb.ca> wrote:
> Thank you for your reply,
> When I notice too many failed queries from this domain name 
> (www.nhc.noaa.gov) restarting the service or clearing the cache (rndc 
> reload), seems to allow queries to work. But still latent (in the 3500ms 
> range)
>
> This is what I get from a DIG +trace...  the connection times out every time.
> #dig +trace www.nhc.noaa.gov
>
> But if I try another domain, example: "cisco.com" it completes properly
> #dig +trace cisco.com
>
> As another test, I ran a trace for www.nhc.noaa.gov on Googles DNS servers 
> (8.8.8.8) and the query seems to time out as well.
> # dig +trace www.nhc.noaa.gov @8.8.8.8
>
>
> ; <<>> DiG 9.11.0-P1 <<>> www.nhc.noaa.gov @*removed DNS-SRV-IP*  +trace
> ;; global options: +cmd
> .   434277  IN  NS  e.root-servers.net.
> .   434277  IN  NS  d.root-servers.net.
> .   434277  IN  NS  f.root-servers.net.
> .   434277  IN  NS  a.root-servers.net.
> .   434277  IN  NS  i.root-servers.net.
> .   434277  IN  NS  h.root-servers.net.
> .   434277  IN  NS  g.root-servers.net.
> .   434277  IN  NS  l.root-servers.net.
> .   434277  IN  NS  b.root-servers.net.
> .   434277  IN  NS  k.root-servers.net.
> .   434277  IN  NS  j.root-servers.net.
> .   434277  IN  NS  c.root-servers.net.
> .   434277  IN  NS  m.root-servers.net.
> ;; Received 811 bytes from *removed DNS-SRV-IP* #53(*removed DNS-SRV-IP*) in 
> 4 ms
>
> gov.172800  IN  NS  a.gov-servers.net.
> gov.172800  IN  NS  b.gov-servers.net.
> gov.172800  IN  NS  c.gov-servers.net.
> gov.172800  IN  NS  d.gov-servers.net.
> gov.86400   IN  DS  7698 8 1 
> 6F109B46A80CEA9613DC86D5A3E065520505AAFE
> gov.86400   IN  DS  7698 8 2 
> 6BC949E638442EAD0BDAF0935763C8D003760384FF15EBBD5CE86BB5 559561F0
> gov.86400   IN  RRSIG   DS 8 1 86400 2017100105 
> 2017091804 15768 . 
> TwWja3x0St/rN8/hvlzI88QouBcsarUYFdo1w73NROAmztwC+I24SyIg 
> /7zygGfvtZtaD4m/ebnS93V0l7Kb7+cP3V/u4Icd0r2U/ub/p0aCqqw+ 
> 4Yc449qZCI04LPSq5q6wnCEI4dK+sSH9RBoLhJ08Obol6+YfHR9zvBSG 
> 0x1+t99i/xSICyHnh/Mcr4Q+7p7Cl+EdgwG8TQIqTOq/qi0n4oTuGixJ 
> BTpcZB5/dhk8oJbPfBiqJDJ6uFQJ5r/kMGYRp9440HaY3BvQ7bqjOHNo 
> QfRybJEv45KZL4mCBGt9HZLkrHqT6Wz4wKflyLlr7JIS7eDzNlraMcqF D9wTaA==
> ;; Received 671 bytes from 193.0.14.129#53(k.root-servers.net) in 64 ms
>
> noaa.gov.   86400   IN  NS  ns-e.noaa.gov.
> noaa.gov.   86400   IN  NS  ns-mw.noaa.gov.
> noaa.gov.   86400   IN  NS  ns-nw.noaa.gov.
> noaa.gov.   3600IN  DS  13774 5 1 
> 4823D2F9C36F98D586ECCD779731F813218BD875
> noaa.gov.   3600IN  DS  13774 5 2 
> C0500C34A55DC61290B397E995A618337594694117A4A667FD3CEF27 EA23AC63
> noaa.gov.   3600IN  RRSIG   DS 8 2 3600 20170925101007 
> 20170918101007 21428 gov. 
> UUOtQnMJgAZQAPS0J259CtXri0WyuDnJsdA5Glqt7FUAnvOFXNCEO8K6 
> 0Kpyp/JHSM6hfeWKoAW3P0IaEeY+nYm91jdZ1Z214sWpiGmjvtE46KV4 
> oVwvwnhyMjqI6gIZ9tTmm67iKz5E4UF524d/liZL9RMqSoy5uL94VUSm tSs=
> ;; Received 483 bytes from 69.36.157.30#53(a.gov-servers.net) in 49 ms
>
> ;; connection timed out; no servers could be reached
>
>
>
>
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of John 
> Miller
> Sent: September 18, 2017 11:03 AM
> Cc: bind-users@lists.isc.org
> Subject: Re: NOAA.GOV domain not working
>
> Hi Ricky,
>
> Try running a "dig +trace www.nhc.noaa.gov," then query each record in the 
> chain and see which one's slow to respond.  I don't see anything crazy in 
>

Re: NOAA.GOV domain not working

[John Miller]

Hi Ricky,

Try running a "dig +trace www.nhc.noaa.gov," then query each record in
the chain and see which one's slow to respond.  I don't see anything
crazy in your named.conf.  Something you didn't mention: does clearing
cache make a difference?

John
-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu


On Mon, Sep 18, 2017 at 8:03 AM, Levesque, Ricky (SNB)
<ricky.leves...@snb.ca> wrote:
> Good day,
>
> I’ve been having an interesting issue with BIND and wondering if anyone has
> had this before or knows how to fix it.
>
>
>
> The issue is,
>
> I have 2 recursive/caching DNS servers running BIND
> 9.9.4-RedHat-9.9.4-51.el7, which are slow to query for this particular
> domain.
>
> Noaa.gov (as well as its sub domains. Specifically – www.nhc.noaa.gov )
>
> By slow I mean, it takes approximately 3500ms to query while most other
> domains take less than 100ms to query.
>
> What’s worst, the domains (noaa.gov) becomes unqueriable after a few hours
> or a day and I need to clear the DNS servers cache to allow it to work
> again.
>
>
>
> The domains have very very low TTL’s (30s) and use DNSsec
>
>
>
> Error:
>
> ##dig www.nhc.noaa.gov
>
> ;; Got answer:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52364
>
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 12, AUTHORITY: 3, ADDITIONAL: 7
>
>
>
> ;; OPT PSEUDOSECTION:
>
> ; EDNS: version: 0, flags:; udp: 4096
>
> ;; QUESTION SECTION:
>
> ;www.nhc.noaa.gov.  IN  A
>
>
>
>
>
> Fixes I have attempted so far:
>
> Reboot servers (2 centos servers running on vmware)
>
> Update system
>
> Try a default config file
>
> Updated vmware tools
>
> Clear DNS cache (temporary fix)
>
> Checked firewall for abnormal data
>
> Updated root hints
>
>
>
> Config:
>
>
>
> acl internal {
>
> *removed*;
>
>localhost;
>
> };
>
>
>
> options {
>
> listen-on port 53 { *removed*;
>
> 127.0.0.1;
>
> ;
>
>};
>
> listen-on-v6 port 53 { none;
>
>#::1;
>
>   };
>
> directory   "/var/named";
>
> dump-file   "/var/named/data/cache_dump.db";
>
> statistics-file "/var/named/data/named_stats.txt";
>
> memstatistics-file "/var/named/data/named_mem_stats.txt";
>
>
>
> dnssec-enable no;
>
> dnssec-validation no;
>
> dnssec-lookaside auto;
>
>
>
> // Conform to RFC1035
>
> auth-nxdomain no;
>
>
>
> // Allowed Port Ranges
>
> use-v4-udp-ports { range 32768 65535; };
>
> use-v6-udp-ports { range 32768 65535; };
>
> recursive-clients 15000;
>
> server-id none;
>
> version none;
>
> interface-interval 0;
>
> allow-query { internal;
>
>   };
>
>   allow-recursion { internal;
>
>   };
>
>  max-ncache-ttl 3600;
>
>  allow-query-cache { internal;
>
> };
>
> };
>
>
>
> logging {
>
> channel default_debug {
>
>   syslog local4;
>
>   severity debug;
>
> };
>
> };
>
___
Please visit https://lists.isc.org/mailman/listinfo/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 DNS records help for single server (and IP), and multi-domain mail server.

[John Miller]

Hi Tom,

You'll want to change your MX records to point to the name, rather
than the IP, of your mail server.  Note that your MX target does _not_
have to be in the same domain as the one it's serving mail for.  For
example:

X.TLD   IN   MX   10 mail.example.com.

is perfectly valid, and quite common for people who don't host their own e-mail.

If you give us some specific domain names that you're hosting for,
we'll be able to help further.

Also, why the wildcard CNAME record?  It's definitely not essential to
your example.

Finally, be _very_ careful about using the SPF qualifier "-all" to
start out with.  What you're saying there is that the only server
authorized to _send_ mail for X.TLD is the one listed in the MX.
Unless people are always logging directly into the mail server to
send, you're better off with "~all" or "?all" to begin with.

John

On Wed, Aug 23, 2017 at 3:28 PM, Tom Browder  wrote:
> I have a single remote server with one IP address (142.54.186.2) I am using
> it to host multiple, independent domains.  I am working on configuring a
> single postfix instance to serve mail for all domains (assuming I can
> successfully rewrite appropriate parts of mail in and out).
>
> From referring to "DNS and BIND" and previous discusssions here and on the
> postfix users list I have re-examined my domain DNS records to see if I can
> cover my requirements more easily.
>
> Given such a configuration described in the first paragraph, does the
> following set of DNS records for a domain look look appropriate:
>
> # For each domain X.TLD:
> X.TLD.  INA 142.54.186.2.
> *.X.TLD.IN   CNAME   X.TLD.
> X.TLD.  INMX  10   142.54.186.2.
> X.TLD.  INTXT "v=spf1 mx -all"
>
> Thanks.
>
> With warmest regards,
>
> -Tom
___
Please visit https://lists.isc.org/mailman/listinfo/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 DNS servers: can they coexist with httpd and mail servers?

[John Miller]

In some cases, running BIND on a web server is exactly what you'd want
to be doing anyway for its caching function.  If you're doing reverse
lookups of IPs or something like that for your Apache logs (I'd
recommend against that, BTW), then you'll save yourself a whole lot of
DNS traffic by running a caching nameserver on the same machine as
Apache.

For a mail server, this is an even better idea: mail servers almost
always do reverse lookups on IP addresses to see if the PTR record
matches what the sender provides in their EHLO.  If you have 20k
e-mails coming from Gmail, for example, no sense in doing the DNS
lookup 20k times.

Of course, you don't have to use BIND to get the benefits of a caching
NS, but if you need to run BIND anyway

John

On Wed, Jul 19, 2017 at 6:37 AM, Tom Browder <tom.brow...@gmail.com> wrote:
> I want to host my own DNS servers, but I need the master to share Bind with
> other services, specifically Apache 2.4, Postfix 3.3, and Mailman 3.
>
> Is there any reason that is not possible?
>
> If not, are there any problems or configuration issues I will need to
> address?
>
> Thanks.
>
> With warmest regards,
>
> -Tom
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: switching entire DNS system to new servers and IP addresses

[John Miller]

On Thu, Feb 23, 2017 at 2:52 PM, Eldridge, Rod A [ITNET]
 wrote:
>
> Iowa State University is replacing 7 ISC NAMED/BIND servers and 4 ISC DHCP 
> servers with Infoblox servers on March 14th. We want to keep the domain names 
> of our external servers the same (with one exception), but we will be 
> changing all of the IPv4 and IPv6 addresses of those external servers.
>
> Current external name servers:
>
>DNS-1.IASTATE.EDU   129.186.6.249, 
> 2610:130:101:100::249
>DNS-2.IASTATE.EDU   129.186.88.249, 
> 2610:130:102:e01::249
>ISU.DNS.NORTHERNLIGHTS.GIGAPOP.NET  146.57.253.249, 2607:ea00:1:9::aa
>
> The exception is that we will be removing ISU.DNS.NORTHERNLIGHTS.GIGAPOP.NET 
> (a server located at the UMN) and will be installing a server at UIowa (that 
> will be named DNS-3.IASTATE.EDU).
>
> The new IPv4 addresses for the new external name servers will be:
>
>DNS-1.IASTATE.EDU   129.186.67.129
>DNS-2.IASTATE.EDU   129.186.67.145
>DNS-3.IASTATE.EDU   128.255.x.x <== not yet 
> assigned
>
> We haven't assigned IPv6 addresses yet.
>
> We'd like advice about any issues or problems we might run into and to watch 
> out for, what preparations should we do or must we do before the switch, and 
> any other advice to help us make this switch go smoothly and unnoticed.
>

Hi Rod,

As Reindl says, if the records are staying the same between InfoBlox
and the UIowa servers, TTLs with Educause may not matter.  That said,
it's worth checking on to be sure the data's the same.  Your own
internal TTLs will definitely be important, though.

Something else to think about are your _reverse_ records.  Everybody
looks at the WHOIS info for their domain, but since ISU has its own
/16 ARIN allocation, don't forget to update things there as well:

dig +trace 186.129.in-addr.arpa NS

in-addr.arpa.172800INNSb.in-addr-servers.arpa.
in-addr.arpa.172800INNSd.in-addr-servers.arpa.
in-addr.arpa.172800INNSf.in-addr-servers.arpa.
in-addr.arpa.172800INNSe.in-addr-servers.arpa.
in-addr.arpa.172800INNSa.in-addr-servers.arpa.
in-addr.arpa.172800INNSc.in-addr-servers.arpa.
;; Received 414 bytes from 192.5.5.241#53(192.5.5.241) in 383 ms

129.in-addr.arpa.86400INNSz.arin.net.
129.in-addr.arpa.86400INNSr.arin.net.
129.in-addr.arpa.86400INNSarin.authdns.ripe.net.
129.in-addr.arpa.86400INNSu.arin.net.
129.in-addr.arpa.86400INNSy.arin.net.
129.in-addr.arpa.86400INNSx.arin.net.
;; Received 158 bytes from 199.212.0.73#53(199.212.0.73) in 5096 ms

186.129.in-addr.arpa.86400INNSdns-1.iastate.edu.
186.129.in-addr.arpa.86400INNSdns-2.iastate.edu.
;; Received 89 bytes from 199.212.0.63#53(199.212.0.63) in 55 ms

186.129.in-addr.arpa.86400INNSdns-1.iastate.edu.
186.129.in-addr.arpa.86400INNS
isu.dns.northernlights.gigapop.net.
186.129.in-addr.arpa.86400INNSdns-2.iastate.edu.
;; Received 225 bytes from 129.186.88.249#53(129.186.88.249) in 42 ms


You may also want to think about public DNS providers.  I know Google
allows you to clear their cache for your records; doing this will help
speed things up for people.

Another thing to think about: do you delegate zones to internal
departments?  Are you slaving any zones for people?

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

Re: Few questions on Bind

[John Miller]

On Thu, Jan 5, 2017 at 6:11 AM, Tony Finch <d...@dotat.at> wrote:
> Debarghya Mandal <debarghya.man...@gmail.com> wrote:
>>
> do, you'll have to write a custom back-end, or use some other more
> scriptable DNS software such as PowerDNS.
>

Thanks, Tony - I didn't quite have the guts to recommend PowerDNS on
the BIND list!

John

-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
___
Please visit https://lists.isc.org/mailman/listinfo/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 IPs Associated With A Single Name

[John Miller]

On Fri, Sep 30, 2016 at 1:15 PM, Tim Daneliuk  wrote:
> On 09/30/2016 11:17 AM, Hrant Dadivanyan wrote:
>> Won't port redirection work better then ?

> get sudo for even limited access to things on their sandboxes.  So, we're
> trying to figure out a way to work around the corporate slowness while
> still living entirely in userland - this lowers the audit risk a lot.

Hi Tim,

Can you spin up virtual machines on your desktops?  It seems like your
situation just screams for tools like Vagrant and Docker, or your own
AWS/Azure/Google environment.  Yours isn't really a DNS problem, per
se, but instead to have a proper development environment.  These days,
it's relatively easy to stand up an entire network within VMware
Workstation, VirtualBox, etc., or even your own local KVM instances.

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

Re: Multiple IPs Associated With A Single Name

[John Miller]

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

On Thu, Sep 29, 2016 at 3:02 PM, Tim Daneliuk <tun...@tundraware.com> wrote:
> In the dark and dusty reaches of my elderly DNS experience, ISTR a way to
> set up A records so that the request to resolve a name returns a *list
> of associated IPs*.  This is distinct from DNS RR (I think?) which
> simply returns a different *single* IP for each call (I may well be wrong).
>
> Can some kind soul point me to a relevant explanation of how to do the
> hostname -> multiple IP mapping?
>
> Thanks,
> --
> 
> 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



-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Organization IP address is getting redirected to a website which does not belong to the organization.

[John Miller]

Hi Sandeep,

The redirect part isn't a DNS issue: I telnetted to port 80 on the IP
address and got:

john@millspad:~$ telnet 146.142.7.113 80
Trying 146.142.7.113...
Connected to 146.142.7.113.
Escape character is '^]'.
GET / HTTP/1.1
Host: 146.142.7.113

HTTP/1.1 302 Found
Date: Sat, 17 Sep 2016 16:30:46 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: PHP/5.4.9-4ubuntu2.3
location: http://www.watcheezy.com/
Vary: Accept-Encoding
Content-Length: 0
Connection: close
Content-Type: text/html

Connection closed by foreign host.

But something is definitely listening on that IP address.  Could be a
rogue device or some sort of routing issue.  Here's a traceroute from
the Brandeis network:

traceroute to 146.142.7.113 (146.142.7.113), 30 hops max, 60 byte packets
 1  129.64.99.1 (129.64.99.1)  1.112 ms  1.127 ms  0.981 ms
 2  * * *
 3  * * *
 4  * * *
 5  te0-7-0-23.ccr21.bos01.atlas.cogentco.com (38.97.106.1)  2.471 ms
2.427 ms  2.375 ms
 6  be2094.ccr41.jfk02.atlas.cogentco.com (154.54.30.13)  8.046 ms
7.721 ms  7.546 ms
 7  be2806.ccr41.dca01.atlas.cogentco.com (154.54.40.106)  13.692 ms
13.661 ms  13.665 ms
 8  be2171.ccr41.iad02.atlas.cogentco.com (154.54.31.106)  14.765 ms
14.832 ms  14.701 ms
 9  verizon.iad02.atlas.cogentco.com (154.54.10.198)  13.629 ms
204.148.79.53 (204.148.79.53)  12.886 ms  12.862 ms
10  0.ae3.XT1.DCA5.ALTER.NET (140.222.225.195)  49.347 ms
0.ae4.XT2.DCA5.ALTER.NET (140.222.225.207)  15.000 ms
0.ae3.XT1.DCA5.ALTER.NET (140.222.225.195)  49.297 ms
11  GigabitEthernet7-0-0.GW9.DCA5.ALTER.NET (152.63.40.21)  14.489 ms
14.502 ms  14.311 ms
12  bls-gw.customer.alter.net (152.179.53.66)  15.437 ms  16.771 ms  16.918 ms
13  146.142.7.129 (146.142.7.129)  17.427 ms  17.338 ms  17.421 ms
14  146.142.7.96 (146.142.7.96)  20.523 ms  20.475 ms  20.421 ms
15  146.142.7.97 (146.142.7.97)  21.510 ms  21.471 ms  21.409 ms
16  146.142.7.83 (146.142.7.83)  18.520 ms  18.453 ms  18.359 ms
17  146.142.7.142 (146.142.7.142)  21.138 ms  21.098 ms  19.436 ms
18  146.142.7.93 (146.142.7.93)  43.152 ms  43.061 ms  43.062 ms
19  146.142.7.66 (146.142.7.66)  133.226 ms  133.169 ms  133.147 ms
20  146.142.7.112 (146.142.7.112)  130.701 ms  130.606 ms  130.737 ms
21  * * *
22  146.142.7.68 (146.142.7.68)  135.039 ms  134.986 ms  134.897 ms
23  146.142.7.132 (146.142.7.132)  127.341 ms  127.256 ms  127.221 ms
24  146.142.7.87 (146.142.7.87)  126.358 ms * *
25  146.142.7.113 (146.142.7.113)  154.693 ms  156.353 ms  156.385 ms

That's one convoluted route to stay in the same /24!  I'd have a chat
with your network admins and see what's up--this doesn't look normal.

Question for you: how'd you uncover the issue?  Do any DNS records
point to 146.142.7.113?  There's no reverse record for it that I can
see.

John

On Sat, Sep 17, 2016 at 11:51 AM, Bhangui, Sandeep - BLS CTR
 wrote:
> Hi
>
> Not exactly sure whether this is a DNS issue but hoping someone here on this 
> forum can provide some advice/suggestion as I am trying to figure out what is 
> going on.
>
> Our organization BLS owns ( registered with the registrar )  the network 
> address 146.142.xxx.xxx.
>
> But if someone  from the Internet [ outside of BLS network )  tries to go to 
> "http://146.142.7.113;   it gets redirected to a site in UK called 
> "us.watcheezy.com"
>
> I have checked the DNS from the BLS  side and we do not have any entry of  
> any kind for  the record  146.142.7.113 on our DNS.
>
> I have also done DNS lookups for watcheezy.com and those seem to be good too 
> with respect to IP and the NS and as to what those NS are reporting.
>
> Can anyone throw some light on as to what is going on here.does not look 
> like a DNS issue to me but I could be wrong.
>
> Thanks
> Sandeep
___
Please visit https://lists.isc.org/mailman/listinfo/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: why this query cause ServFail

[John Miller]

Hillary,

I suspect there's more going on behind the scenes than just what your
tcpdump shows here.  Can you please post your named.conf file so we
can all see if there are any forwarders, stub zones, etc. involved
here?

Second thing: after you flush your cache, does the same behavior
persist, or does BIND try a different nameserver?

Finally, can you post the tcpdump command you're using?

John

On Sat, Sep 10, 2016 at 1:39 PM, Hillary Nelson
<nelsonhilla...@gmail.com> wrote:
> Thanks John, I've changed the resolver-query-timeout from default 10 to 30
> seconds thought my nameserver should have enough time to query at least one
> other nameservers of production.tacc.utexas.edu before gets timed out. But
> still it stuck with the one that's not working instead of trying other
> nameservers. This is the tcpdump as you can see my nameserver 192.168.1.100
> keeps querying 129.114.13.17 four times within the 30 seconds, shouldn't it
> try the one of the other nameservers ?
>
> 22:24:32.594680 IP 10.79.1.6.42064 > 192.168.1.100.53: 25767+ [1au] A?
> web1.production.tacc.utexas.edu. (60)
> 22:24:32.595029 IP 192.168.1.100.65437 > 129.114.13.17.53: 27989% [1au] A?
> web1.production.tacc.utexas.edu. (60)
> 22:24:37.594642 IP 10.79.1.6.42064 > 192.168.1.100.53: 25767+ [1au] A?
> web1.production.tacc.utexas.edu. (60)
> 22:24:41.595312 IP 192.168.1.100.19764 > 129.114.13.17.53: 8074% [1au] A?
> web1.production.tacc.utexas.edu. (60)
> 22:24:42.594873 IP 10.79.1.6.42064 > 192.168.1.100.53: 25767+ [1au] A?
> web1.production.tacc.utexas.edu. (60)
> 22:24:50.595523 IP 192.168.1.100.62364 > 129.114.13.17.53: 18009 A?
> web1.production.tacc.utexas.edu. (49)
> 22:24:59.595825 IP 192.168.1.100.58124 > 129.114.13.17.53: 57314 A?
> web1.production.tacc.utexas.edu. (49)
> 22:25:02.595236 IP 192.168.1.100.53 > 10.79.1.6.42064: 25767 ServFail 0/0/1
> (60)
>
> I'll contact the admin for the domain to gets the broken nameserver fixed,
> but seems to me there is also problem with how named handle the NS of this
> domain, or there is other parameter to tell named to try to loop through
> other nameservers if one fails.
>
>
>
> On Fri, Sep 9, 2016 at 7:20 PM, John Miller <johnm...@brandeis.edu> wrote:
>>
>> Hi Hillary,
>>
>> By default, BIND will return SERVFAIL to the client if it can't
>> complete the full iteration process within 10 seconds.  This is
>> controllable by the "resolver-query-timeout" parameter.  As for why
>> your recursive server doesn't just try elsewhere, it _will_, but it
>> assumes that it's querying a valid nameserver, so the original query
>> needs to time out first.  It takes several queries for BIND to get its
>> round-trip time cache in order.  With six authoritative NSs, it'll
>> take longer than if you only had three.
>>
>> As for 129.114.13.18 being lame - it's hard to be lame if you aren't
>> getting responses.  Lame just means that responses from the nameserver
>> aren't authoritative, even though it's listed in your NS records.
>>
>> Your best option is to fix the non-responding nameservers or remove
>> them from your NS records if they aren't supposed to respond to
>> queries - name resolution isn't just broken for you, it's broken for
>> everyone who wants to find web1.production.tacc.utexas.edu.
>>
>> John
>>
>> On Fri, Sep 9, 2016 at 5:23 PM, Hillary Nelson <nelsonhilla...@gmail.com>
>> wrote:
>> > Also should mention that our BIND is 9.9.8-P4, what confuses me here is
>> > that
>> > the listed nameserver (129.114.13.18) is lame and our nameserver (
>> > 192.168.1.100) can't get any responses from it(see tcpdump above), why
>> > our
>> > nameserver try other listed NS servers  instead sending 'ServFail' to
>> > the
>> > client(10.79.1.6) ?
>> > Any help will be greatly appreciated!
>> >
>> > On Fri, Sep 9, 2016 at 1:07 PM, Hillary Nelson
>> > <nelsonhilla...@gmail.com>
>> > wrote:
>> >>
>> >> We've been seeing sporadic failure of resolve this name
>> >> web1.production.tacc.utexas.edu from our nameserver.
>> >>
>> >> There are 6 NS listed for domain production.tacc.utexas.edu, two of the
>> >> six don't seem to work(dc1.production.tacc.utexas.edu 129.114.13.17 and
>> >> dc2.production.tacc.utexas.edu 129.114.13.18).
>> >>
>> >> If our nameserver hits the two and doesn't get any response, it sends
>> >> 'ServFail' to client, shouldn't the our nameserver keeps trying the
>> >> other
>> >> four working nameservers listed for the 

Re: why this query cause ServFail

[John Miller]

Hi Hillary,

By default, BIND will return SERVFAIL to the client if it can't
complete the full iteration process within 10 seconds.  This is
controllable by the "resolver-query-timeout" parameter.  As for why
your recursive server doesn't just try elsewhere, it _will_, but it
assumes that it's querying a valid nameserver, so the original query
needs to time out first.  It takes several queries for BIND to get its
round-trip time cache in order.  With six authoritative NSs, it'll
take longer than if you only had three.

As for 129.114.13.18 being lame - it's hard to be lame if you aren't
getting responses.  Lame just means that responses from the nameserver
aren't authoritative, even though it's listed in your NS records.

Your best option is to fix the non-responding nameservers or remove
them from your NS records if they aren't supposed to respond to
queries - name resolution isn't just broken for you, it's broken for
everyone who wants to find web1.production.tacc.utexas.edu.

John

On Fri, Sep 9, 2016 at 5:23 PM, Hillary Nelson  wrote:
> Also should mention that our BIND is 9.9.8-P4, what confuses me here is that
> the listed nameserver (129.114.13.18) is lame and our nameserver (
> 192.168.1.100) can't get any responses from it(see tcpdump above), why our
> nameserver try other listed NS servers  instead sending 'ServFail' to the
> client(10.79.1.6) ?
> Any help will be greatly appreciated!
>
> On Fri, Sep 9, 2016 at 1:07 PM, Hillary Nelson 
> wrote:
>>
>> We've been seeing sporadic failure of resolve this name
>> web1.production.tacc.utexas.edu from our nameserver.
>>
>> There are 6 NS listed for domain production.tacc.utexas.edu, two of the
>> six don't seem to work(dc1.production.tacc.utexas.edu 129.114.13.17 and
>> dc2.production.tacc.utexas.edu 129.114.13.18).
>>
>> If our nameserver hits the two and doesn't get any response, it sends
>> 'ServFail' to client, shouldn't the our nameserver keeps trying the other
>> four working nameservers listed for the domain ?
>>
>> Here is the tcpdump:
>>
>> 12:33:38.593146 IP 10.79.1.6.51980 > 192.168.1.100.53: 60950+ [1au] A?
>> tas.tacc.utexas.edu. (48)
>> 12:33:38.593573 IP 192.168.1.100.54985 > 129.114.13.18.53: 40455% [1au] A?
>> web1.production.tacc.utexas.edu. (60)
>> 12:33:43.593131 IP 10.79.1.6.51980 > 192.168.1.100.53: 60950+ [1au] A?
>> tas.tacc.utexas.edu. (48)
>> 12:33:47.593796 IP 192.168.1.100.49009 > 129.114.13.18.53: 38559% [1au] A?
>> web1.production.tacc.utexas.edu. (60)
>> 12:33:48.593234 IP 10.79.1.6.51980 > 192.168.1.100.53: 60950+ [1au] A?
>> tas.tacc.utexas.edu. (48)
>> 12:33:48.593583 IP 192.168.1.100.53 > 10.79.1.6.51980: 60950 ServFail
>> 0/0/1 (48)
>>
>>
>> Thanks in advance for your help!
>>
___
Please visit https://lists.isc.org/mailman/listinfo/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: Disabling rate-limit?

[John Miller]

On Mon, Aug 15, 2016 at 11:23 PM, blrmaani  wrote:
> From tcpdump, it appears that customers are receiving delayed response and 
> are too sensitive for timeouts.
>
> The queries they are sending are authoritative i.e the zone is on our 
> nameserver.
>
> How do I trouble-shoot this issue? This is really intermittent and hard to 
> reproduce..

I'm a little confused: if your clients are _sending_ queries, they're
either sending recursive queries, or they're acting as nameservers
themselves and are sending iterative queries, following delegation to
resolve names outside of your domain.

If your clients are _replying_ to queries, then they are acting as
authoritative nameservers--answering queries for records in your
domain.

To dig into things further, nameserver logs and errors would be
helpful, as would your config.  You might also consider doing a
selective packet capture on your nameservers for the clients that are
having problems.

If you haven't already, I highly recommend picking up a copy of Albitz
and Liu's _DNS_and_BIND_: it's a bit dated, but still a good
introduction to the basics of BIND.

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

Re: Disabling rate-limit?

[John Miller]

Hi Blr,

First things first: if your customers are sending queries, this is
probably about their own recursive queries timing out, rather than
incoming authoritative queries timing out.

Something else you should check: are your customers receiving a
delayed (say a few seconds) SERVFAIL response, or are they receiving
no response at all?

There's a different set of options in BIND for recursive rate limiting
versus authoritative rate limiting.

Recursive queries:

* recursive-clients
* clients-per-query
* max-clients-per-query

Running 'rndc status' is a good way to see how close you are to these
limits; you'll see log messages like

"no more recursive clients: quota reached"

There's also a newer set of "recursive client rate-limiting" features
available in newer (9.9 and 9.10) versions of BIND, but I'm pretty
sure this doesn't apply to your case.

Authoritative queries:
https://kb.isc.org/article/AA-00994/0/Using-the-Response-Rate-Limiting-Feature-in-BIND-9.10.html
IIRC, rate-limiting for authoritative queries (called "Response rate
limiting" or "RRL") wasn't enabled by default until BIND 9.10.x, and
required a specific build in BIND 9.9.x.  It's not available in BIND
9.8.x.

John

On Mon, Aug 15, 2016 at 9:22 PM, blrmaani <blrma...@gmail.com> wrote:
> I inherited a DNS server which is running BIND 9.8.x. There was a DNS 
> incident where our customers complained that they saw query timeouts 
> intermittently (Our customers run cassandra/hadoop applications and send same 
> queries repeatedly). They also run nscd on their hosts but I was told all 
> have same TTL value of 3600 indicating all names expire at the same time on 
> thousands of client hosts).
>
>  I tried to reproduce the issue by sending hostname.bind queries and I see 
> logs similar to the one below:
>
>   named[]: limit responses to  for 
> hostname.bind CH TXT 
>   named[]: *stop limiting responses to  
> for hostname.bind CH TXT 
>
>
> I reviewed /etc/named.conf and do not see 'rate-limit' configuration. I am 
> confused because BIND ARM says rate-limit is disabled by default. But logs 
> indicate otherwise.
>
> ( I did "grep rate /etc/*" and didn't see anything. There are no includes in 
> named.conf)
>
> Please advice on how I can disable rate-limit on my DNS server.
>
>
> I did a strings on 'named' binary and see this:
>
> strings /usr/sbin/named | egrep -i rrl
> dns_rrl
> dns_rrl_init
> dns_rrl_view_destroy
>
> What else do I need to check to identify if RRL is enabled?
>
>
> 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



-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Intermittent Issues Resolving Microsoft Hostnames

[John Miller]

Ok--I see what's up now!  This has been one of the stranger DNS setups
I've ever seen: different NS records pointing to overlapping sets of
IP addresses, EDNS disabled, really short TTLs on both NS and A
records.  Even though you're not querying at the name listed in the NS
records, it's usually the same IP under the hood, so

# dig +noedns zulily-com.mail.protection.outlook.com.
@ns1-prodeodns.glbdns.o365filtering.com.

should work--it's only when the nameserver itself fails to resolve
that things go funny.

If things are working for you now, I'll leave you be.  Thanks for a
really interesting problem!

John

On Wed, May 4, 2016 at 4:52 PM, Rob Heilman  wrote:
> That is a valid NS for the *.mail.oe.outlook.com hostnames.  Probably got
> wires crossed between the different examples.  Either way I could not
> resolve that server name at that time.  Now it is responding 100% of the
> time for both *.mail.oe.outlook.com and *.mail.protection.outlook.com hosts.
>
> -Rob Heilman
>
>
>
> ;mail.eo.outlook.com. IN NS
>
> ;; ANSWER SECTION:
> mail.eo.outlook.com. 10 IN NS ns2-prodeodns.glbdns.o365filtering.com.
> mail.eo.outlook.com. 10 IN NS ns1-prodeodns.glbdns.o365filtering.com.
>
> ;; ADDITIONAL SECTION:
> ns1-prodeodns.glbdns.o365filtering.com. 6 IN A 207.46.100.42
> ns1-prodeodns.glbdns.o365filtering.com. 6 IN A 65.55.169.42
> ns1-prodeodns.glbdns.o365filtering.com. 6 IN A 157.56.112.42
> ns2-prodeodns.glbdns.o365filtering.com. 30 IN A 207.46.163.143
> ns2-prodeodns.glbdns.o365filtering.com. 30 IN A 207.46.163.176
> ns2-prodeodns.glbdns.o365filtering.com. 30 IN A 157.55.234.42
>
> ;; Query time: 9 msec
> ;; SERVER: 10.10.10.21#53(10.10.10.21)
> ;; WHEN: Wed May  4 16:47:26 2016
> ;; MSG SIZE  rcvd: 210
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Intermittent Issues Resolving Microsoft Hostnames

[John Miller]

On Wed, May 4, 2016 at 3:57 PM, John Miller <johnm...@brandeis.edu> wrote:
> On Wed, May 4, 2016 at 3:23 PM, Rob Heilman <rheil...@echolabs.net> wrote:
>> Could it be that the “adberr:2” logs entries are indicating that it 
>> periodically can’t find the name servers?
>>
>> -Rob Heilman
>>
>>
>>
>> # dig zulily-com.mail.protection.outlook.com. 
>> @ns1-prodeodns.glbdns.o365filtering.com.
>>
>> dig: couldn't get address for 'ns1-prodeodns.glbdns.o365filtering.com.': 
>> failure
>>
>>
>
> Nothing quite so fancy there - I think you're querying the wrong
> nameserver.  Try
>
> mail.protection.outlook.com. 1800 INNS
> ns2-proddns.glbdns.o365filtering.com.
> mail.protection.outlook.com. 1800 INNS
> ns1-proddns.glbdns.o365filtering.com.
>
> instead.  Just looks like a typo on your end.
>
> John

Although you could argue that this _is_ a rodeo:

"prodeodns"

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

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

Re: Intermittent Issues Resolving Microsoft Hostnames

[John Miller]

On Wed, May 4, 2016 at 3:23 PM, Rob Heilman  wrote:
> Could it be that the “adberr:2” logs entries are indicating that it 
> periodically can’t find the name servers?
>
> -Rob Heilman
>
>
>
> # dig zulily-com.mail.protection.outlook.com. 
> @ns1-prodeodns.glbdns.o365filtering.com.
>
> dig: couldn't get address for 'ns1-prodeodns.glbdns.o365filtering.com.': 
> failure
>
>

Nothing quite so fancy there - I think you're querying the wrong
nameserver.  Try

mail.protection.outlook.com. 1800 INNS
ns2-proddns.glbdns.o365filtering.com.
mail.protection.outlook.com. 1800 INNS
ns1-proddns.glbdns.o365filtering.com.

instead.  Just looks like a typo on your end.

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

Re: Intermittent Issues Resolving Microsoft Hostnames

[John Miller]

>
> dig mail.protection.outlook.com. ns
> @ns1-proddns.glbdns.o365filtering.com. +noedns
> ;; ANSWER SECTION:
> mail.protection.outlook.com. 10 IN  NS
> ns1-proddns.glbdns.o365filtering.com.
> mail.protection.outlook.com. 10 IN  NS
> ns2-proddns.glbdns.o365filtering.com.
>
>
>
> Note the short TTL on the A and NS records, combined with dns servers
> that don't understand edns. Is there something in bind 9.9.5 that would
> not like that combination? I presume that 9.9.5 would try edns first,
> and then backoff to noedns after receiving the FORMERR.
>

Seems very odd to have a TTL of 10 seconds on an NS record: anyone
seen that before?  Combining that with EDNS disabled means that you're
essentially having to make four lookups every single time you want to
use Outlook 365.

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

Re: Adding CNAME for the root domain issue

[John Miller]

> But this is getting way off topic for BIND-users, and should probably be
> moved to dns-operati...@dns-oarc.net if we want to continue.

Much obliged!

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

Re: Adding CNAME for the root domain issue

[John Miller]

If your domain is ourweddingaccount.com, and you're looking to have
the apex record

ourweddingaccount.com.CNAME some.other.domain.

but still host other records in the ourweddingaccount.com zone, you
can't.  That's not how CNAME records work.  A CNAME record is an alias
for a particular _label_ within a zone.  It's meant to do things like

myserver.ourweddingaccount.com.   CNAME   some.other.domain.

What you're saying here is that the name "myserver" will always point
to "some.other.domain" __regardless_of_record_type__.  If you're
trying to do this for the __apex_record__ of your zone (just your
domain name, no hostname), you're saying that you don't need SOA or NS
records for your zone--it's a contradiction in terms.  You _must_ use
an A or  record.  Period.

If you're running a web site on a host whose IP address changes
frequently, may I suggest that you let someone else manage your DNS
for you?  Plenty of DNS companies do this:

https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root
http://docs.aws.amazon.com/govcloud-us/latest/UserGuide/setting-up-route53-zoneapex-elb.html
https://devcenter.heroku.com/articles/apex-domains
https://blog.dnsimple.com/2014/01/why-alias-record/

Otherwise, I suggest that you read

http://serverfault.com/questions/613829/why-cant-a-cname-record-be-used-at-the-apex-aka-root-of-a-domain

If you want to manage your own DNS, you need to understand how DNS
works and what its limitations are.

John

On Wed, Apr 27, 2016 at 10:05 AM, Daniel Dawalibi
 wrote:
> Hello John
>
> The below is not working on our BIND version BIND 9.10.0-P2 unless it is 
> working on other version
>
> Domain.com.  CNAME  x.y.com.
> www CNAME x.y.com.
>
> Errors returned when adding these records:
>
> general: dns_master_load: ourweddingaccount.com.db.inter:13: 
> ourweddingaccount.com: CNAME and other data
>
>
> If we proceed with the below work around by replacing the CNAME with A 
> record, It will resolve but our setup requires a CNAME record.
>
> Domain.com.  A  IPaddress
> www CNAME x.y.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

Re: statistics-channels not serving rdtype records

[John Miller]

On Thu, Apr 7, 2016 at 3:42 PM, Ben Wilson  wrote:
> Hi,
>
> I'm not sure what is different on a new server I'm setting up, but when
> querying the port configured for statistics-channels, no rdtype records are
> included.
>
> resstat, socket, task, etc are all there, but not the number of queries.
>
> My version:
> ii  bind9   1:9.9.5.dfsg-3ubuntu0.8  amd64
> Internet Domain Name Server
> ii  bind9-host  1:9.9.5.dfsg-3ubuntu0.8  amd64
> Version of 'host' bundled with BIND 9.X
> ii  bind9utils  1:9.9.5.dfsg-3ubuntu0.8  amd64
> Utilities for BIND
> ii  libbind9-90 1:9.9.5.dfsg-3ubuntu0.8  amd64
> BIND9 Shared Library used by BIND

Hi Ben,

Can you show us your statistics-channels {} blocks from both your old
server and your new server config?  That'll be easier than trying to
compare Ubuntu package versions or anything like that.

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

Re: Recursive bind becomes unresponsive with high load

[John Miller]

On Thu, Mar 31, 2016 at 2:00 PM, Michael Brunnbauer  wrote:
>
> hi all,
>
> On Thu, Mar 31, 2016 at 07:32:21PM +0200, Michael Brunnbauer wrote:
>> Is is possible that is this connected to rndc stats? I will stop doing
>> rndc stats for a while to test (it currently runs every minute).
>
> Not doing rndc stats did not prevent the problem. Any other ideas?

Hi Michael,

Are you doing query logging on this box? If so, you might check for
messages such as:

named[743]: clients-per-query decreased to 17

I know you tried setting max-clients-per-query earlier, but since this
is for a locally-hosted zone, query volume could be quite high
somewhere along the way.  Likewise, you might run

rndc status

and see what you get.

Something else you might try: if you don't already, turn on
server-statistics/statistics-channels:

https://kb.isc.org/article/AA-00769/0/Using-BINDs-XML-statistics-channels.html

You may get what you're looking for; you may not.

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

Re: Multiple A records and reverse DNS

[John Miller]

Which FQDN does your mail server use for its EHLO?  It should use the
same name that's listed in reverse DNS.

John

On Thu, Mar 17, 2016 at 9:53 AM, Thomas Schulz <sch...@adi.com> wrote:
> This is not a BIND question but I hope people here will know the answer.
> We are switching service providers and I understand that many email SPAM
> prevention systems insist on the reverse DNS matching the forward DNS.
> If I have two A records for our mail server and the reverse record matches
> one of them, will that be good enough. Or will the fact that the other A
> record does not match cause trouble.
>
> Tom Schulz
> Applied Dynamics Intl.
> sch...@adi.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



-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: A Zone Transfer Question

[John Miller]

On Fri, Feb 19, 2016 at 9:26 PM, Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <mailman.268.1455921931.73610.bind-us...@lists.isc.org>,
>  John Miller <johnm...@brandeis.edu> wrote:
>
>> And if you actually want people to use your zone or you want NOTIFY
>> working, two NS records (and possibly glue) are really a must.
>
> He mentioned that these are internal nameservers, they're not reached
> via public delegation. So NS records are probably irrelevant to how
> they're used by clients.

Fair enough.  There's certainly no need for two NS records if nobody's
following delegation here.  In the case of dynamic updates, one NS
record might actually be better: there's no worrying about update
forwarding between slave and master.

Will a zone even load with zero NS records?  It's not something I've
ever tried, though probably should for grins.

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

Re: A Zone Transfer Question

[John Miller]

Regardless of how NOTIFY's behaving (it's a nice-to-have, not a must),
you need to make sure zone transfers from master to slave are working.
If you can run

dig @10.4.1.101 rack1.com AXFR

from your slave, then zone transfers of rack1.com are working from
master to slave, and your issue lies somewhere in your config - a
serial number didn't get updated on the master?  Zone changes didn't
get saved?  Didn't actually reload the zone after editing the zone
file?

If your dig command doesn't work, then it might be either a config
issue or a networking issue - you'll have to figure out which.

And if you actually want people to use your zone or you want NOTIFY
working, two NS records (and possibly glue) are really a must.

Don't worry about dynamic updates at this point: make sure that when
you edit a zone file manually, increment the serial number, and reload
the zone on the master, that the slave fetches the zone within the
refresh interval.  Gotta walk before you run ;-)

John

On Fri, Feb 19, 2016 at 3:56 PM, David Li <dlipub...@gmail.com> wrote:
> 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;
>>&

Re: A Zone Transfer Question

[John Miller]

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

Re: Tuning for lots of SERVFAIL responses

[John Miller]

>> I was going to respond with the same advice --
>> slave your internal zones -- but then I somehow convinced myself that "recurs
>> ive-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 name
>> d would still drop any new RD=1 query whenever the quota was full.
>
> For some reason people are afraid to slave internal zones.  Back
> when I was working for CSIRO I used to slave all the internal zones
> for all of the sites the division had.  Each site administered its
> own zones but all sites slaved all of them.  That way local and
> inter site lookups always succeeded even when the external links
> were down.

Something I just thought of: how did you manage your NS records in
this situation?  To get NOTIFY/IXFR to work properly, either you have
to list every one of your recursive servers in your local NS records
or you have to do an also-notify block on the master.  Or you just
skip the NOTIFY/IXFR altogether and set very low refresh values on
your zones!  How did you handle standing up/taking down servers
quickly?

Another question: Is it just the master and slave zone types that
bypass the recursive-clients limit?  Presumably forward and stub types
still come up against the limit b/c BIND still has to track a backend
connection somewhere.

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

Re: Tuning for lots of SERVFAIL responses

[John Miller]

On Thu, Feb 18, 2016 at 5:06 PM, Mark Andrews  wrote:
> For some reason people are afraid to slave internal zones.  Back
> when I was working for CSIRO I used to slave all the internal zones
> for all of the sites the division had.  Each site administered its
> own zones but all sites slaved all of them.  That way local and
> inter site lookups always succeeded even when the external links
> were down.

It wasn't so much a fear thing for us as a configuration thing: we
previously were using a pair of nameservers for everything under the
sun.  Not being sure if we would do BIND for recursive DNS (or
authoritative, for that matter), it was far easier to migrate things
piecemeal.  Using stub zones on the resolvers makes configuration far
simpler as well.  We're also in an interesting place where our
internal zones aren't _really_ internal: everything for the most part
has a .brandeis.edu FQDN, and the world sees largely the same set of
records that we do locally.  We have to keep everything synced up
somehow.

Is slaving internal zones like this feasible with other DNS products
(NSD, PowerDNS)?  Both of those run different binaries for their
authoritative and recursive functions, so this seems like a
BIND-specific (or BIND9, at least) way of doing things.

We'll definitely be increasing recursive-clients (likely to something
~10k).  I'd imagine that we'll also start slaving our own zones
again--we just need to figure out the config management piece of
things.  Shouldn't take more than a day or two, though.  Thanks for
the advice, Mark.

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

Re: Tuning for lots of SERVFAIL responses

[John Miller]

Thanks for the reply, Tony. With the recent glibc bug, I figured most
folks would be off putting out those fires!

On Thu, Feb 18, 2016 at 3:04 PM, Tony Finch <d...@dotat.at> wrote:
> John Miller <johnm...@brandeis.edu> wrote:
>
>> A couple of weeks ago, we experienced an outage on our external
>> Internet links.  Ideally, this shouldn't affect queries for internal
>> resources - we expect those queries to continue to be answered.
>
> We've had a few connectivity losses over the last year due to floods and
> DDoS attacks, so I have more experience with this than I would like.
>
> It's tricky. There are a surprising number of external dependencies on
> supposedly internal resources. For instance we have a web single-sign-on
> service which deliberately avoids using the Typekit font specified by our
> web designers, but it's still "slow" when we lose external connectivity
> because (I think) of attempts at TLS OCSP lookups :-(

We've run into similar issues in the past: people were hitting a
captive portal that didn't allow access to the CAs for OCSP
verification.  We essentially had to poke holes in our captive portal
to make sure all of that traffic got through.  The captive portal
thing isn't so much an issue any longer, but I'd bet you some of our
service outages were due to OCSP lookups failing.  This is a case
where I really wish more things would use OCSP stapling - there's no
reason not to for internal TLS-protected resources.

>
>> It's my understanding that by default, BIND limits the number of
>> concurrent recursive queries to 1000, so obviously during these
>> situations, we need to raise our client limit (recursive-clients) to
>> deal with this.
>
> Our recursive servers are built using BIND 9.10's ./configure
> --with-tuning=large option, and I have bumped up the max-clients option to
> 12345 (a number that I guessed but which turned out to be about right). We
> normally deal with about 1500-2000 qps on each server; during outages I
> observed this increased by a factor of 3 or 4. However the number of
> active clients went up to nearly 10,000 (it's normally negligible). The
> other reason 12345 is about right is that the default socket limit is
> 20,000 and each client seems to need two sockets.
>

We're not quite there with regard to traffic volume: we're somewhere
around 150 qps on each server (maybe 5-600 qps campus-wide), but as
happened to you, we saw the same 3-4x spike in volume.  Likewise, we
went from roughly 20 active clients per server (going off of UDP
socket stats from sar) to over 1000.  The servers themselves were
quietly twiddling their thumbs at 0.1 load: strictly a case of the
application doing the throttling.

>> What I'm curious about is how BIND behaves when it can't finish
>> iterative queries: when someone queries for yahoo.com, and the root
>> (or .com, yahoo.com) nameservers aren't reachable, does BIND then
>> issue a SERVFAIL response (assuming yes)?
>> How long will BIND wait before returning SERVFAIL?
>> At what point does BIND assume a domain is down altogether?  What's
>> the behavior then?
>
> Good questions :-)
>
> Tony.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Tuning for lots of SERVFAIL responses

[John Miller]

A couple of weeks ago, we experienced an outage on our external
Internet links.  Ideally, this shouldn't affect queries for internal
resources - we expect those queries to continue to be answered.

That being said, we saw a bunch of messages in our logs such as:

client 192.168.1.2#56075: no more recursive clients (1000/0/1000): quota reached

It's my understanding that by default, BIND limits the number of
concurrent recursive queries to 1000, so obviously during these
situations, we need to raise our client limit (recursive-clients) to
deal with this.

What I'm curious about is how BIND behaves when it can't finish
iterative queries: when someone queries for yahoo.com, and the root
(or .com, yahoo.com) nameservers aren't reachable, does BIND then
issue a SERVFAIL response (assuming yes)?
How long will BIND wait before returning SERVFAIL?
At what point does BIND assume a domain is down altogether?  What's
the behavior then?

In other words, how do we keep ourselves from being overwhelmed with
unanswerable queries during a network outage?

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

Re: What is the use of having a chroot path during installation of Bind

[John Miller]

On Thu, Jan 14, 2016 at 4:01 PM, Reindl Harald <h.rei...@thelounge.net> wrote:
>
>
> Am 14.01.2016 um 21:48 schrieb John Miller:
>>
>> Thanks for the advice, Mike.  We chrooted our install because it was
>> "best practice" security-wise, but from an administration standpoint,
>> it's been a bit of a headache: for example, you have to keep straight
>> what goes in /etc and /var/named/chroot/etc, you end up setting a
>> $BIND_CHROOT environment variable for everyone to keep paths shorts at
>> the CLI, etc.
>
>
> no, you need to just put a symlink

Fair enough.

> how often do you *by hand* touch things?

Only when something's not working as expected, or when we want to
verify that configuration has changed.

> normally anything is done with backends and scripts

Yep - via Puppet and scripting for us, mostly.

> so after once configured it don't matter if things are bekow
> /var/named/chroot/ or on a higher directory - is it worth - well, the
> question is "does it harm" and it don't after initial deployment when done
> right

For the most part, I agree with you here.  That said, for someone with
very little BIND and Unix experience--say someone who primarily
manages Windows--to come in and understand a chrooted installation
isn't as easy as a non-chrooted install.  Granted, it's probably
easier than getting up to speed on SELinux, but you're still adding a
learning curve.

> security is about layers

Agreed as well - you need to keep up on patches, limit access, use
firewalls, set up secure zone transfers, rotate keys, use an
unprivileged user, architect your systems properly, etc.  I can also
see benefit in a chroot environment guarding against OS-level
attacks--key loggers, trojans, unauthorized daemons, shell
vulnerabilities, etc.: the attacker's damage is limited to BIND.
Likewise, if your server is in privileged network space, it may be
able to compromise other systems more easily.  Sounds like my original
reply was glib and misleading here.  I still think "what's the
tradeoff between ease of use and knowledge transfer" versus security
is worth discussion, however.

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

Re: What is the use of having a chroot path during installation of Bind

[John Miller]

Thanks for the advice, Mike.  We chrooted our install because it was
"best practice" security-wise, but from an administration standpoint,
it's been a bit of a headache: for example, you have to keep straight
what goes in /etc and /var/named/chroot/etc, you end up setting a
$BIND_CHROOT environment variable for everyone to keep paths shorts at
the CLI, etc.

I'd recommend _not_ chrooting for internal-only servers: it hasn't
been worth the trouble for us.  For public-facing nameservers, I'd
consider a little more carefully, but with everything running on its
own VM these days, plus SELinux, containers, etc., there are tools out
there that provide at least the security of a chroot environment, and
almost certainly better.  The days of "hardware's expensive; let's run
everything on one box," where a chroot environment might have been
valuable, are _way_ behind us!

John

On Thu, Jan 14, 2016 at 10:42 AM, Mike Hoskins (michoski)
 wrote:
> Yes you can run without the chroot.  Years ago it was considered best
> practice to chroot and most power users would have said you were insane not
> to do so.  Now there are increasingly many who say it's not worth the effort
> (fairly easy to get around in many cases) -- do a bit of google engineering
> and you will see pros/cons.
>
> If you are using packages from your distro (looks like it from the "el6" and
> ancient version) this will often just be pulled in by default.  If you build
> your own packages, use upstream repos, ISC packages or something like this:
>
> http://www.five-ten-sg.com/mapper/bind
>
> Then you can just install without the chroot.  Entirely up to you, BIND can
> work either way.  As I said, if you search a bit you'll find older "best
> practices" like these which suggest chroot (note the dates!):
>
> https://www.cymru.com/Documents/secure-bind-template.html
>
> https://deepthought.isc.org/article/AA-00768/0/Getting-started-with-BIND-how-to-build-and-run-named-with-a-basic-recursive-configuration.html
>
> Then increasing amounts of documentation saying it is largely irrelevant due
> to adding minimal value due to some known issues in the chroot mechanism
> itself, named -u, etc:
>
> https://deepthought.isc.org/article/AA-00874/0
>
> """
> If following the preceding advice (running BIND as an unprivileged user on a
> dedicated server) chrooting is "de-emphasized." Our operations experts feel
> that chrooting does not substantially improve security under those
> conditions and do not affirmatively recommend it, but they do not explicitly
> discourage it.
> """
>
> From:  on behalf of Harshith Mulky
> 
> Date: Thursday, January 14, 2016 at 1:46 AM
> To: "bind-users@lists.isc.org" 
> Subject: What is the use of having a chroot path during installation of Bind
>
> Hello,
>
>
> When installing bind, the following 2 are installed
>
>
> bind-9.8.2-0.17.rc1.el6.x86_64
> bind-chroot-9.8.2-0.17.rc1.el6.x86_64
>
>
> What is the need of this bind-chroot?
>
>
>
> I see all files in /var/named path are softlinks to
> /var/named/chroot/var/named
>
>
> and
>
>
> /etc/named.conf is softlink to /var/named/chroot/etc/named.conf
>
>
>
>
> What is this chroot binding? And why is this chroot Binding Required?
>
>
>
> Can the named server function without this chroot Binding?
___
Please visit https://lists.isc.org/mailman/listinfo/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: Mitigation of server's load by queries for non-existing domains

[John Miller]

On Wed, Jan 13, 2016 at 8:35 AM, Tomas Hozza  wrote:
> On 12.01.2016 18:16, Tony Finch wrote:
>> Tomas Hozza  wrote:
>>>
>>> Recently I was trying to find a mechanism in BIND that could prevent the
>>> server from processing a recursive query for non-existing domains.
>>
>> Have a look at https://www.isc.org/blogs/tldr-resolver-ddos-mitigation/
>>
>>> I was thinking about using RPZ with QNAME policy trigger, but this
>>> applies only to the responses to queries and still makes the server to
>>> try to resolve it.
>>
>> RPZ has a "qname-wait-recurse no" option.
>
> This is exactly the thing I was looking for.
>
> Thank you very much!
>

Thanks from this end as well--I wasn't aware of this option, either.

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

Re: Why two lookups for a CNAME?

[John Miller]

>>
>> Using dig, I find play.google.com is a CNAME for play.l.google.com.
>>
>>
>> When asked to resolve it, named will first look for play.google.com.  The
>> result
>> will include the CNAME and the IP of the A record.
>>
>>
>> Named then makes a second request to resolve the A record.
>
> Are you sure about this example?
>
> That would be the correct behavior if the target of the CNAME were
> delegated to different servers than the CNAME itself. But both
> google.com and l.google.com are served by ns[1-4].google.com.
>
> You'll see additional queries like this if you look up servers hosted by
> the Akamai CDN, because the CNAME points from the original domain to one
> of Akamai's domains.

Hi Barry,

I just did a double-check (stock RHEL 6 BIND, 9.8.2), and BIND indeed
does do the second lookup for play.l.google.com.  I've attached a pcap
file if anyone's curious.

John

-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu


play.google.com.pcap
Description: application/vnd.tcpdump.pcap
___
Please visit https://lists.isc.org/mailman/listinfo/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: RPZ - override TXT records

[John Miller]

Hi Wolfgang,

If you have a CNAME record, no other resource types can exist for the
same fqdn (label).  A CNAME literally means: "look here instead for
every single record with this name."  So if you want to override a
single TXT record for www.cisco.com, you'll need to include the other
resource records for www.cisco.com in your RPZ zone file as well.

John

On Thu, Oct 8, 2015 at 5:25 PM, Wolfgang Riedel [CISCO]
<wolfg...@cisco.com> wrote:
> Hi Folks,
>
> I am currently struggling with using RPZ for inserting or overriding TXT
> resource records.
>
> This is my goal:
>
> ; do not rewrite www.cisco.com (so, PASSTHRU) and add or override missing
> metadata
> www.cisco.com  CNAME rpz-passthru.
> www.cisco.com  TXT
> "CISCO-CLS=app-name:HTTP|app-class:TD"
>
> What work's is that I can do one or the other but not both at the same time
> if I need to use a CNAME.
>
> This works:
>
> wolfgang.dns-as.org A   193.34.28.108
> wolfgang.dns-as.org TXT
> "CISCO-CLS=app-name:RPZ|app-class:TD"
>
> but in reality this will not work for CDN or load-balanced sites which don't
> have fixed IP address.
>
> Any hint's what I am doing wrong?
>
> Many thanks,
> Wolfgang
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Speeding up DNS change propagation

[John Miller]

On Fri, Sep 18, 2015 at 2:35 PM, Danny Sinang  wrote:
> Hi,
>
> Our vendor is changing their FTP server's IP address tomorrow.
>
> 1. How can I tell how long their DNS change will propagate to us ?

Whatever TTL you have cached when the vendor makes the switch is how
long it'll take for your caching servers to pick up the change.

>  a. Do I just run dig a "ftp.example.com" and look for the TTL for that
> DNS entry ?
>  b. Every time I run that command, the TTL is shrinking. How do I find
> out the full TTL for it ?

If you want to know the full TTL, ask the company's NSs directly -
authoritative servers only give out the full TTL.

> 2. Can I just restart BIND tomorrow to clear its cache and force it to query
> the "example.com" name server for "ftp.example.com" (so as not to wait for
> the propagation to reach us) ?

Sure can.  Depending on your BIND version, you can also run rndc
flushname  and it'll clear just that name from your cache.

If the TTL is very long, don't forget about client-side caching as
well.  Windows and OS X cache DNS lookups by default.

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

Re: Speeding up DNS change propagation

[John Miller]

The .com nameservers don't know anything about ftp.example.com; they
just know the nameservers for example.com.  So have no fear -- BIND
will not cache an upstream response for ftp.example.com: you'll only
hear about ftp.example.com from the example.com nameservers.

Pretty much all upstream nameservers: root NSs, .com NSs, example.com
NSs--are authoritative-only.  They don't cache or offer cached
responses.  (Not 100% accurate, but nearly always so.)

John

On Fri, Sep 18, 2015 at 2:58 PM, Danny Sinang <d.sin...@gmail.com> wrote:
> As a follow-up to your answer for question #2, after my clearing the cache
> or restarting BIND, won't BIND find an old cache of "ftp.example.com" in the
> ".com" top level DNS server ?
>
> Regards,
> Danny
>
> On Fri, Sep 18, 2015 at 2:51 PM, John Miller <johnm...@brandeis.edu> wrote:
>>
>> On Fri, Sep 18, 2015 at 2:35 PM, Danny Sinang <d.sin...@gmail.com> wrote:
>> > Hi,
>> >
>> > Our vendor is changing their FTP server's IP address tomorrow.
>> >
>> > 1. How can I tell how long their DNS change will propagate to us ?
>>
>> Whatever TTL you have cached when the vendor makes the switch is how
>> long it'll take for your caching servers to pick up the change.
>>
>> >  a. Do I just run dig a "ftp.example.com" and look for the TTL for
>> > that
>> > DNS entry ?
>> >  b. Every time I run that command, the TTL is shrinking. How do I
>> > find
>> > out the full TTL for it ?
>>
>> If you want to know the full TTL, ask the company's NSs directly -
>> authoritative servers only give out the full TTL.
>>
>> > 2. Can I just restart BIND tomorrow to clear its cache and force it to
>> > query
>> > the "example.com" name server for "ftp.example.com" (so as not to wait
>> > for
>> > the propagation to reach us) ?
>>
>> Sure can.  Depending on your BIND version, you can also run rndc
>> flushname  and it'll clear just that name from your cache.
>>
>> If the TTL is very long, don't forget about client-side caching as
>> well.  Windows and OS X cache DNS lookups by default.
>>
>> 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
>
>



-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Installing bind is not very clear for me

[John Miller]

On Fri, Sep 4, 2015 at 3:29 PM,   wrote:
>> One Firewall should be enough.
>> So, what you consider this firewall should do ?
>> In my opinion:
>> Block requests coming from a blacklist (Who will generate this list ?)
>> Block denial of service requests. It needs to measure the requests rate
>> to detects when is under attack.
>> Block port scanners on publics ips.
>
> Before you put a firewall in front of a public facing name server,
> you might want to consider slide 16 of the following presentation:
>
> https://app.box.com/s/a3oqqlgwe15j8svojvzl
>
> The slide headline is "Stateful firewalls in front of servers
> considered harmful!" - and the author has ample arguments for his
> point of view.
>

Oh man  Depending on your query volume, a stateful firewall in
front of a public NS sounds like a recipe for disaster--that
connection tracking table would get large quite quickly.  We run
host-based firewalls on our DNS servers--but they're stateless on port
53.  (uses the raw table in iptables to disable connection tracking)

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

Re: A tale of two nameservers - resolution problems

[John Miller]

On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz <r...@htt-consult.com> wrote:
>
>
> On 09/01/2015 09:20 AM, John Miller wrote:
>>
>> If you check pcap, logs, etc., is the server's following delegation
>> for 0.centos.pool.ntp.org? Where do outbound packets stop?
>
>
> I don't believe this and I have some serious problems.
>
> Part of my challenge is I am running the new server on an armv7 board that
> does not have a rtc.  So when the system boots, the time is jan 1 1970.  The
> first thing you want to run is ntp to set the time, but requires named
> running and resolving.
>
> For the 'fun' of it, I used 'date' to set the time to now, and then no
> problem resolving 0.centos.pool.ntp.org.  So there is something about that
> resolution that does not like the early date.
>
> So I am caught in a time bind here!
>
> Is there anyway to get bind not to be particular about system time at first?


Hopefully this isn't a production server... rtc's kind of important
;-)  I'll ditto here and say: static /etc/hosts entries or static IPs
in ntp.conf.

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

Re: A tale of two nameservers - resolution problems

[John Miller]

If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where do outbound packets stop?

John

On Tue, Sep 1, 2015 at 9:09 AM, Robert Moskowitz  wrote:
> I have one nameserver running bind 9.8.2 and a new one running 9.9.4.
>
> Both can resolve www.ietf.org
>
> Only the 9.8.2 can resolve 0.centos.pool.ntp.org
>
> I literally rsynced all the of the conf and zone files from the old to the
> new, then changed all of the server name references.  I have done this
> before.  I have another box running the 9.8.2 code that I built the same way
> and it resolves both fqdns just fine.
>
> I am a lost at what is the problem.  Both have the same named.conf:
>
> //
> //
>
> include "/etc/named/named.acl";
>
> options
> {
> listen-on port 53 { any; };
> listen-on-v6 port 53 { any; };
>
> allow-query{ localhost; };
> allow-query-cache{ localhost; };
> recursion no;
>
> directory "/var/named";
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named_stats.txt";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
>
> //dnssec-enable yes;
> //dnssec-validation yes;
> //dnssec-lookaside auto;
>
> dnssec-enable no;
> dnssec-validation no;
>
> /* Path to ISC DLV key */
> //bindkeys-file "/etc/named.iscdlv.key";
>
> //managed-keys-directory "/var/named/dynamic";
>
>
> };
> logging
> {
> /*  If you want to enable debugging, eg. using the 'rndc trace' command,
>  *  named will try to write the 'named.run' file in the $directory
> (/var/named).
>  *  By default, SELinux policy does not allow named to modify the
> /var/named directory,
>  *  so put the default debug log file in data/ :
>  */
> channel default_debug {
> file "data/named.run";
> severity dynamic;
> };
> };
>
> view "internal"
> {
>
> include "/etc/named/named.internal";
>
> };
> view"external"
> {
>
> include "/etc/named/named.external";
>
> };
>
> include "/etc/named/rndc.key";
>
> ==
> and named.internal has:
>
> /* This view will contain zones you want to serve only to "internal" clients
>  * that have addresses that are not on your directly attached LAN interface
> subnets:
>  */
> match-clients{ httnets; };
> match-destinations{ httnets; };
> allow-query{ httnets; };
> allow-query-cache{ httnets; };
> allow-recursion{ httnets; };
> recursion yes;
> empty-zones-enable yes;
>
> //include "/etc/named/named.trusted.key";
> include "/etc/named.rfc1912.zones";
>
> zone "." IN {
> type hint;
> file "named.root";
> };
>
> // These are your "authoritative" internal zones:
>
> zone "htt-consult.com" {
> type master;
> file "httin-consult.com.zone";
> };
>
> etc.
>
>
> ==
>
>
> Is the dnssec disabled possibly the problem?  Like required now?
___
Please visit https://lists.isc.org/mailman/listinfo/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

[John Miller]

On Wed, Aug 5, 2015 at 10:18 AM, Gary Carr garycarr...@gmail.com wrote:

 Overall, is breaking this function out - internally - really worth it?


I can offer a personal testimonial on the management aspects of this:

A couple of years back, we made the switch from combined
authoritative/recursive servers to recursive-only and
authoritative-only systems.  The reasoning was more a logistics thing
than anything else: we wanted to host our authoritative records both
locally and with a cloud service, and moving the recursive portion was
easy to do.  We also weren't sure which daemons we wanted to use for
each side of things - PowerDNS recursor?  BIND?  unbound?  PowerDNS
authoritative?  NSD? - so separating the two functions gave us
flexibility in that arena.  It also meant we didn't have to worry
about views.  We treated the separation of authoritative and recursive
as gospel.

For recursive service, we initially ran three pdns-recursor instances
and two BIND instances, most behind a hardware load balancer.  For
authoritative service, we kept our records in Amazon Route 53, syncing
with four internal NSs: one hidden master and three slaves.  This let
us override records locally as needed and meant that we didn't have to
follow delegation from the root NSs (important - you're not relying on
100% border uptime for your internal network).

We've since moved our recursive stuff to BIND (for RPZ), and have
added a couple of additional internal authoritative servers, so we're
at 10+ DNS servers locally.  We're starting to become too complicated!
 Separating authoritative and recursive functions certainly makes it
easier to do maintenance and change daemons as necessary, but it's
added a layer of complexity that you might not want.

Something interesting we did is that our recursive servers don't
depend exclusively on our local authoritative servers.  In a pinch
(last master in the stub zone), they'll go out to our cloud DNS
servers and pull/follow delegation from there.  So the dependence of
recursive on authoritative, due to separation, isn't nearly as great.

John
-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
___
Please visit https://lists.isc.org/mailman/listinfo/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: tsig indicates error

[John Miller]

On Fri, Jul 24, 2015 at 10:52 AM, Managed Pvt nets m...@icabs.co.zw wrote:

  Hi All,

 I have recently built a server to act as a secondary / slave for my zones.
 Built on Debian 8.1 and running BIND 9.9.5. On trying to transfer zones
 from my master I am getting this error here, what could I be missing:

 ===
 Jul 24 15:33:55 huffer named[493]: zone myzonename.co.zw/IN: refresh:
 failure trying master aaa.bbb.ccc.ddd#53 (source 0.0.0.0#0): tsig indicates
 error
 ===


Hi Mollatt,

This usually means what it says: there's an error with the TSIG
authentication between master and slave.  Make sure you've got your
allow-transfer statements configured with the proper keys, that you've got
server {} blocks configured with the proper keys, and that a copy of the
slave key lives on the master.

If you're not intending to use TSIG, make sure your master doesn't require
it and that your slave doesn't try to use it for its AXFRs.

John
-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
___
Please visit https://lists.isc.org/mailman/listinfo/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: tsig indicates error

[John Miller]

On Fri, Jul 24, 2015 at 11:52 AM, Mark Elkins m...@posix.co.za wrote:

 On Fri, 2015-07-24 at 15:44 +, Managed Pvt nets wrote:
 
 
  On 24/07/2015 5:05:24 PM, Alan Clegg a...@clegg.com wrote:
 
   Possible problems:
  Mismatched keys.
  Mismatched key names.
  Mismatched clocks.
 
  Most likely mismatched key.  I have to figure out how to make sure my
  master does not require TSIGs and my slave does not try to use them.


 TSIG is a step towards better security. Rather learn how to use it than
 go backwards. I see TSIG as a step towards DNSSEC...


I'm with Mark on this.  TSIG isn't that tough to figure out--a couple hours
and you should have it down.  Cricket/Paul's book, and Pro DNS and BIND 10
are good intros to the subject.  I'm installing a copy of Debian 8.1 for
myself right now--I'm curious to see what the stock BIND config looks like
(we use RHEL here at the office).

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

Re: stumped on sub domain addition

[John Miller]

Hi Donovan,

Your zone file(s) as well as your named.conf config would be best here.  We
really need more information from you than a single fqdn.

John
-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu



On Thu, Jul 23, 2015 at 12:40 PM, lists - euca li...@euca.us wrote:

 Hello,
 I added a sub domain to my zone file euca.us yesterday.

 “onqsolutions”.

 It first was added as a CNAME, then I couldn’t get it to work.. so now it
 is an A record.
 Still not working.

 Can someone help troubleshoot?

 onqsolutions.euca.us

 TIA,
 Donovan


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

[John Miller]

On Thu, Jul 23, 2015 at 2:22 PM, lists - euca li...@euca.us wrote:

 Here is the file that smbind created  (note that I have been making some
 changes):
 $TTL   21600
 @   IN  SOA ns10.euca.us. hostmaster.euca.us. (
 2015072342  ; Serial
 10800   ; Refresh
 7200; Retry
 604800  ; Expire
 21600)  ; Negative Cache TTL
 ;
 @   IN  NSns10.euca.us.
 @   IN  NSns11.euca.us.
 @   IN  A   209.236.238.19
 @   IN  MX  10  mail.euca.us.
 design  IN  CNAME   @
 dev IN  CNAME   @
 elatia  IN  A   209.236.238.19
 ftp IN  A   209.236.238.19
 mailIN  A   209.236.238.18
 mail2   IN  A   209.236.238.18
 ns10IN  A   209.236.238.21
 ns11IN  A   209.236.238.22
 onqsolutionsIN  A   209.236.238.19
 www IN  CNAME   @
 www-tek IN  CNAME   @



Hmm... that should work as a CNAME without any problems.  If you change it
back to a CNAME, does the serial number increment?  Also, you don't have a
separate zone set up for onqsolutions.euca.us--it's just a single record,
right?

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

Re: servfail only for a zone

[John Miller]

Something I'm noticing is that your SOA record fields are quite small:

aquilacorde.com.3600INSOAns1.virtualbit.it.
info.aquilacorde.com. 2015070601 1200 180 3600 3600

Specifically, your expiration time (first of the 3600s) is set to one
hour.  This means that if ns2 hasn't contacted ns1 in an hour, the zone
will be invalid on ns2.  If you're making a whole ton of updates, then the
small times make sense, but for the zone you posted, that doesn't seem to
be the case.  Normally it's not a problem, but if you can't respond to a
communication outage between the two nameservers within an hour, the second
will stop working.

This is just a guess, but network communication/failed zone transfer seems
the most likely culprit for something like this (entire zone returns
SERVFAIL).

John
-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu

On Mon, Jul 13, 2015 at 1:19 PM, Lucio Crusca lu...@sulweb.org wrote:


 And here is the aquilacorde.com zonefile at the master ns1:


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

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

Re: servfail only for a zone

[John Miller]

On Mon, Jul 13, 2015 at 2:15 PM, Lucio Crusca lu...@sulweb.org wrote:


 You have been persuasive enough, I'm definitely going to raise the expire
 value, but now the question is: are the SERVFAIL replies a consequence of
 the low expire value?


It doesn't help your cause _at_all_.  There could be a few reasons why
you're getting SERVFAIL responses from your second nameserver, but the zone
being expired is the most likely.  Check everything:

- physical connectivity between ns2 and ns1
- zone transfer settings (allow-transfer, allow-notify, TSIG settings and
keys, etc.)

A sample troubleshooting sequence run from ns2 might look something like:

- Can you ping ns1 from ns2?
- Can you query ns1 (dig @ns1) from ns2?
- Can you do a manual zone transfer from ns1 to ns2: dig @ns1
aquilacorde.com AXFR
- If you're using TSIG for your zone transfers, you'll need to set the
appropriate options in dig.
- On ns2, can you run rndc reload on aquilacorde.com?  What do your logs
say when you do this?
- What happens when you increment the zone's serial number on ns1?  Does
ns1 automatically send a NOTIFY?
- If you're able (there aren't other zones to worry about), what happens
when you restart BIND on ns2?  What do the logs say?

If you've done most of these troubleshooting steps, you'll know whether you
have:
- basic network connectivity
- basic DNS connectivity (UDP port 53)
- DNS zone transfer connectivity (TCP port 53; AXFR uses TCP)
- DNS zone transfer ability
- useful logging

and... CHANGE YOUR EXPIRE VALUE NOW!!

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

Re: dig @server foobar +trace +recurse

[John Miller]

For my part, I'd be curious to know what sort of problem you're trying to
solve with dig.  We might be able to shed a little more light on what the
best command would be for you.

The +recurse gets overridden when you use +trace:

+[no]recurse
   ... Recursion is automatically disabled when the
   +nssearch or +trace query options are used.

so you're getting iterative queries whether you want them or not: +trace
means you're treating yourself as a recursive nameserver, and the RD bit
isn't set on your queries.

If you send a single query to a remote nameserver, you're only going to get
a single response--that's how DNS works.  So if you're looking to see the
chain of lookups that a remote recursive nameserver takes to reach its
final response, you can run dig +trace from the remote nameserver, or you
could run a series of dig @server +norecurse hostname queries to get what
you're looking for.

I admit ignorance on the +showsearch option: I'm not seeing the query flags
change, nor am I seeing any different output when I run:

dig @8.8.8.8 trombone.org +showsearch

;  DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1  @8.8.8.8 trombone.org
+showsearch
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 9742
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

versus

dig @8.8.8.8 trombone.org

;  DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1  @8.8.8.8 trombone.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 36891
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

Even after flushing Google's cache (
https://developers.google.com/speed/public-dns/cache), I still get the same
response.  Does anyone have insight on +showsearch, other than the
following ;-)

BUGS
   There are probably too many query options.


John



On Wed, Jul 8, 2015 at 6:34 PM, Anne Bennett a...@encs.concordia.ca wrote:


 I've been trying to debug a problem with dig, and it has finally
 occurred to me that, if I understand this correctly, the +trace
 option essentially overrides the @server specification, except for
 the initial query for the root zone nameservers.  (I was using
 +showsearch +trace +recurse.)

 Is my understanding correct?


___
Please visit https://lists.isc.org/mailman/listinfo/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: #service named restart fails with a weird message

[John Miller]

Semicolons!  You need one for the second ip range in your list, and you
need one after the zone file for your localhost zone.  The error message
really does tell you what you need in this case ;-)  The config you pasted
only has nine lines, so I'm assuming that the last error really is on line
8/9 and something got lost in posting to the list.

John

On Fri, Jun 19, 2015 at 2:12 PM, Samad Agha samad.agha2...@gmail.com
wrote:

 Hey Gurus,
 When I try to restart named, it fails with the following message:

 [root@new-dns2 ~]# service named restart
 Stopping named:[  OK  ]
 Starting named:
 Error in named configuration:
 /etc/named.conf:3: missing ';' before '}'
 /etc/named.conf:11: missing ';' before '}'
[FAILED]
 [root@new-dns2 ~]#

 And here is what my simple named.conf looks like:

 [root@new-dns2 ~]# cat /etc/named.conf
 options {
  directory /var/named;
 allow-recursion {207.151.36.0/24; 206.117.117.0/24};
  };

 zone 0.0.127.in-addr.arpa {
 type master;
 file db.127.0.0
 };
 [root@new-dns2 ~]#

 What am I doing wrong? Can you please assist?

 Many thanks in advance and have a nice day.

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

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

Re: How reliable is RPZ in production? I'm seeing flakiness in testing.

[John Miller]

Hi Anne,

We've been using RPZ in production for over six months, and haven't
had any serious issues.  We haven't encountered this specific type of
flakiness, but then again, it's likely our configs and bind versions
aren't the same either: we do our quarantining at layer 2.

You might start things out by giving us your bind version and your
response-policy {} config.  Also print out the exact rules (one or two
examples should suffice) you're using for client quarantining --
that'll help narrow things down.  Also, how are you publishing to your
client quarantine zones?  Presumably you're using some sort of DDNS
publishing that gets triggered when a client does something
suspicious.

John
-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu


On Tue, Jan 6, 2015 at 5:52 PM, Anne Bennett a...@encs.concordia.ca wrote:
 I'm playing with RPZ with a view to both quarantining internal
 compromised or vulnerable hosts, and capturing attempts at
 communication with known external bad hosts.  I start with a
 fairly extensive whitelist, to avoid lying about any of my own
 hosts, and to give truthful answers for patch sites, so that my
 users can patch their systems even when otherwise quarantined.

 The masters for my RPZs do not themselves use the zones
 for policy (nor do they recurse on queries).  However the
 nameservers that do recursive resolution for my network are
 slaves for those RPZs, and *do* use them for policy.

 My set-up works, but sporadically - it's as though the RPZs wink
 in and out of use for no apparent reason, even when I'm not
 changing the data.  At one point while testing last December,
 my by-client-IP test quarantine rule just stopped matching
 (based on no logged hits, and no redirection of my queries
 from the quarantined host).  Only a restart of named on the
 resolver brought the quarantine back, but then the whitelist
 worked only partially.

 I don't know what to make of this; it looks as though the
 technology is several years old, and my experience with ISC
 bind is usually excellent.  Has anyone else encountered this
 type of flakiness?

 If not, any advice about how to debug this?
___
Please visit https://lists.isc.org/mailman/listinfo/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 Migration best practice steps

[John Miller]

On Tue, Dec 16, 2014 at 5:29 PM, John Goubeaux
goube...@education.ucsb.edu wrote:
 Hello Folks,

 I'm running a Primary Master Bind Version 9.3.2 on a crusty old Solaris 9
 Sparc box that is starting to act up. Needless to say I need to move this
 service onto new Hardware/OS ASAP.


 I've got a  9.81 Version up and running on Ubuntu 12.04 ( installed via the
 latest pkg available)  but am unclear how to best proceed in migrating the
 live zone files to it AND minimize any downtime in the service.

 Should I configure the newer build as a secondary master or slave first,
 then make it the master after I see that it works/behaves properly ?

 Or should I migrate the configuration and zone files over and bring down
 both old and new then change the IP in the new build to the old NS's IP then
 bring it up ?

 Also, I can see that the Debian version has a slightly different config file
 arrangement, but looks like this should NOT be an issue as long as I migrate
 the data over appropriately.

 Thanks for any insight on how to best proceed here !

Hi John,

First things first, some more info on your overall DNS infrastructure
and how the 9.3.2 server fits in would be helpful.

- Is this for education.ucsb.edu, other zones, or both?
- Is the 9.3.2 server authoritative-only, or does it serve recursive
requests as well?
- Is the 9.3.2 server listed in any of the NS records of the zones you
host, or just the SOA record (public vs. hidden master?)
- How many slaves are you running?  Do all of your zones slave from
the 9.3.2 master, or do some point to other masters?
- A copy of the SOA and NS records of your zones (assuming all are
identical) would also be helpful, as would copies of your named.conf
files if you're worried about your configuration at all.

The main principle here is that you shouldn't take down the 9.3.2
server until you're _sure_ the 9.8.1 server is fully ready to roll.
Ideally you should be able to do this with zero downtime, but much
depends on your setup.  It's certainly not something you want to rush.

John
-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Bind Migration best practice steps

[John Miller]

Thanks for the response, John.  Helps a bunch to know that you just
have the single zone to worry about.  I also did a quick dig on
education.ucsb.edu (NS  SOA records).  Looks like you're not running
any of your own slaves, but are making use of two main university
servers as slaves: ns1.ucsb.edu  ns2.ucsb.edu.

So... copy the zone file directly or set up the 9.8.1 box as a slave?
You've only got one zone, so personal preference would be just to copy
 over your zone file and config; that'd keep you from having to set up
the 9.8.1 server in slave mode at all.  Obviously if you have a ton of
churn in your zones (frequent dynamic updates, for example), that'd
change things.  I suspect you're OK there, though :-).

At that point, just test the 9.8.1 server to make sure it's ready,
give your upstream DNS admins a shout (perhaps have them test zone
transfers against the new server), then schedule the IP swap.
Shouldn't have to take much more downtime than an ifdown on the old
guy and an ifup on the new one (and any ARP stuff on your routers).
You have two slaves that can cover for you during this brief window,
so downtime will be minimal.

John

On Tue, Dec 16, 2014 at 6:30 PM, John Goubeaux
goube...@education.ucsb.edu wrote:
 Thanks for the quick reply John,

 I answered some of the items in-line


 Hi John,

 First things first, some more info on your overall DNS infrastructure
 and how the 9.3.2 server fits in would be helpful.

 - Is this for education.ucsb.edu, other zones, or both?


 The NS is ONLY for  education.ucsb.edu

 - Is the 9.3.2 server authoritative-only, or does it serve recursive
 requests as well?


 It is autoritative for education.ucsb.edu only

 - Is the 9.3.2 server listed in any of the NS records of the zones you
 host, or just the SOA record (public vs. hidden master?)



 Yes, there is an A record for it as well as the SOA records and it is
 public.

 - How many slaves are you running?  Do all of your zones slave from
 the 9.3.2 master, or do some point to other masters?



 I am NOT running any slaves at this point, just this one Master.

 - A copy of the SOA and NS records of your zones (assuming all are
 identical) would also be helpful, as would copies of your named.conf
 files if you're worried about your configuration at all.

 The main principle here is that you shouldn't take down the 9.3.2
 server until you're _sure_ the 9.8.1 server is fully ready to roll.
 Ideally you should be able to do this with zero downtime, but much
 depends on your setup.  It's certainly not something you want to rush.

 John
 --
 John Miller
 Systems Engineer
 Brandeis University
 johnm...@brandeis.edu
 (781) 736-4619
 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to
 unsubscribe from this list

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



 --
 John Goubeaux
 Systems Administrator
 Gevirtz Graduate School of Education
 UC Santa Barbara
 Education 4203C
 805 893-8190



-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Promoting slave to master DNS server with dynamic updates

[John Miller]

 cannot be considered as liable for the content of this
 message unless the sender has been duly authorized and has acted strictly
 in the course of his/her tasks as an employee.

 The sender of this e-mail cannot ensure the security of its electronic
 transmission and consequently will not be liable should its content be
 altered.
 **

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

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




-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS slave not synced after successfully zone transfer

[John Miller]

:42.486 general: debug 1: zone_maintenance: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
 24-Jul-2014 14:48:42.486 general: debug 1: zone_dump: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
 24-Jul-2014 14:48:42.486 general: debug 1: zone_settimer: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
 24-Jul-2014 14:48:42.486 general: debug 1: zone_gotwritehandle: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
 24-Jul-2014 14:48:42.490 general: debug 1: dump_done: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
 24-Jul-2014 14:48:42.490 general: debug 3: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: dns_journal_compact: not
 found

 

 Anyone has any idea what could be wrong?

 Best regards,
 Ricardo Esteves.


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

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




-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS slave not synced after successfully zone transfer

[John Miller]

To check your cache, just run rndc dump.  It'll write a dump of the BIND
cache to your data directory (wherever you've got it configured).

John


On Thu, Jul 24, 2014 at 10:51 AM, Ricardo Esteves maverick...@gmail.com
wrote:

  Hi,

 It seems it's taking some time to sync after the transfer, because now it
 resolves ok with the new data.

 nslookup 192.168.250.101 192.168.2.251
 Server:192.168.2.251
 Address:192.168.2.251#53

 101.250.168.192.in-addr.arpaname = openerp-bold.vi.pt.


 nslookup 192.168.250.101 192.168.2.252
 Server:192.168.2.252
 Address:192.168.2.252#53

 101.250.168.192.in-addr.arpaname = openerp-bold.vi.pt.


 After the transfer i checked the new zone file and it was exactly the same
 as the master one.

 If i make a new change to the master how can i then check if
 101.250.168.192.in-addr.arpa PTR is cached?


 On 24-07-2014 15:35, John Miller wrote:

  On NS #2, if you run rndc freeze/rndc thaw, what does the actual zone
 file look like?  Also, what does your cache look like?  Is
 101.250.168.192.in-addr.arpa PTR cached?

  John


 On Thu, Jul 24, 2014 at 10:25 AM, Ricardo Esteves maverick...@gmail.com
 wrote:

  Hi,

 I've got two bind9 servers, one master (192.168.2.251) and one slave
 (192.168.2.252).

 I've configured zone transfers, and after a change of a zone on the
 master, the slave gets the notification, downloads successfully the new
 zone file, but still has the old information in memory:

 nslookup 192.168.250.101 *192.168.2.251*
 Server:192.168.2.251
 Address:192.168.2.251#53

 *101.250.168.192.in-addr.arpaname = openerp-bold.xpto.com
 http://openerp-bold.xpto.com.*

 nslookup 192.168.250.101 *192.168.2.252*
 Server:192.168.2.252
 Address:192.168.2.252#53

 *101.250.168.192.in-addr.arpaname = demoopenerp1.xpto.com
 http://demoopenerp1.xpto.com.*

 --

 Log on the slave:

 24-Jul-2014 14:48:42.481 notify: info: client 192.168.2.251#61865: view
 vi_local_resolver: received notify for zone '250.168.192.in-addr.arpa'
 24-Jul-2014 14:48:42.481 general: info: master 192.168.2.251#53 (source
 192.168.2.252#0) deleted from unreachable cache
 24-Jul-2014 14:48:42.482 general: debug 1: queue_soa_query: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
 24-Jul-2014 14:48:42.482 general: debug 1: soa_query: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
 24-Jul-2014 14:48:42.482 general: debug 3: dns_request_createvia
 24-Jul-2014 14:48:42.482 general: debug 3: request_render
 24-Jul-2014 14:48:42.482 general: debug 3: requestmgr_attach:
 0x801f11170: eref 1 iref 1
 24-Jul-2014 14:48:42.482 general: debug 3: mgr_gethash
 24-Jul-2014 14:48:42.482 general: debug 3: req_send: request 0x8037eaea8
 24-Jul-2014 14:48:42.482 general: debug 3: dns_request_createvia: request
 0x8037eaea8
 24-Jul-2014 14:48:42.482 general: debug 3: req_senddone: request
 0x8037eaea8
 24-Jul-2014 14:48:42.483 general: debug 3: req_response: request
 0x8037eaea8: success
 24-Jul-2014 14:48:42.483 general: debug 3: req_cancel: request 0x8037eaea8
 24-Jul-2014 14:48:42.483 general: debug 3: req_sendevent: request
 0x8037eaea8
 24-Jul-2014 14:48:42.483 general: debug 1: refresh_callback: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
 24-Jul-2014 14:48:42.483 general: debug 3: dns_request_getresponse:
 request 0x8037eaea8
 24-Jul-2014 14:48:42.483 general: debug 1: refresh_callback: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: serial: new 2014072417, old
 2014070617
 24-Jul-2014 14:48:42.483 general: debug 3: dns_request_destroy: request
 0x8037eaea8
 24-Jul-2014 14:48:42.483 general: debug 3: req_destroy: request
 0x8037eaea8
 24-Jul-2014 14:48:42.483 general: debug 3: requestmgr_detach:
 0x801f11170: eref 1 iref 0
 24-Jul-2014 14:48:42.483 general: debug 1: queue_xfrin: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
 24-Jul-2014 14:48:42.484 general: info: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: Transfer started.
 24-Jul-2014 14:48:42.484 general: debug 1: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: requesting IXFR from
 192.168.2.251#53
 24-Jul-2014 14:48:42.484 xfer-in: info: transfer of
 '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53:
 connected using 192.168.2.252#51302
 24-Jul-2014 14:48:42.484 xfer-in: debug 3: transfer of
 '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53:
 requesting IXFR for serial 2014070617
 24-Jul-2014 14:48:42.484 xfer-in: debug 3: transfer of
 '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: sent
 request length prefix
 24-Jul-2014 14:48:42.484 xfer-in: debug 3: transfer of
 '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: sent
 request data
 24-Jul-2014 14:48:42.486 xfer-in: debug 3: transfer of
 '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: got
 nonincremental response
 24-Jul-2014 14:48:42.486 general: debug 1

Re: DNS slave not synced after successfully zone transfer

[John Miller]

+1.

Both Windows and Mac cache DNS records, so if you had the old one cached
prior to making the change, you'd either have to flush your local cache or
wait for the record's TTL to expire.

On Linux, at least, nslookup is a deprecated tool: dig is better in many
ways.  In Windows, obviously, nslookup is all you've got by default :-(

John



On Thu, Jul 24, 2014 at 4:44 PM, Leonard Mills l...@yahoo.com wrote:

 You may be seeing additional buffering from nslookup.
 If you are using nslookup on a Windows platform,
 I'm 99.44% confident that you are observing M$ client-side
 buffering.  DiG (or even host) are much better than nslookup
 for diagnostic purposes.

 hth


   On Thursday, July 24, 2014 8:00 AM, John Miller johnm...@brandeis.edu
 wrote:


 To check your cache, just run rndc dump.  It'll write a dump of the BIND
 cache to your data directory (wherever you've got it configured).

 John


 On Thu, Jul 24, 2014 at 10:51 AM, Ricardo Esteves maverick...@gmail.com
 wrote:

  Hi,

 It seems it's taking some time to sync after the transfer, because now it
 resolves ok with the new data.

 nslookup 192.168.250.101 192.168.2.251
 Server:192.168.2.251
 Address:192.168.2.251#53

 101.250.168.192.in-addr.arpaname = openerp-bold.vi.pt.


 nslookup 192.168.250.101 192.168.2.252
 Server:192.168.2.252
 Address:192.168.2.252#53

 101.250.168.192.in-addr.arpaname = openerp-bold.vi.pt.


 After the transfer i checked the new zone file and it was exactly the same
 as the master one.

 If i make a new change to the master how can i then check if
 101.250.168.192.in-addr.arpa PTR is cached?


 On 24-07-2014 15:35, John Miller wrote:

  On NS #2, if you run rndc freeze/rndc thaw, what does the actual zone
 file look like?  Also, what does your cache look like?  Is
 101.250.168.192.in-addr.arpa PTR cached?

  John


 On Thu, Jul 24, 2014 at 10:25 AM, Ricardo Esteves maverick...@gmail.com
 wrote:

  Hi,

 I've got two bind9 servers, one master (192.168.2.251) and one slave
 (192.168.2.252).

 I've configured zone transfers, and after a change of a zone on the
 master, the slave gets the notification, downloads successfully the new
 zone file, but still has the old information in memory:

 nslookup 192.168.250.101 *192.168.2.251*
 Server:192.168.2.251
 Address:192.168.2.251#53

 *101.250.168.192.in-addr.arpaname = openerp-bold.xpto.com
 http://openerp-bold.xpto.com/.*

 nslookup 192.168.250.101 *192.168.2.252*
 Server:192.168.2.252
 Address:192.168.2.252#53

 *101.250.168.192.in-addr.arpaname = demoopenerp1.xpto.com
 http://demoopenerp1.xpto.com/.*

 --

 Log on the slave:

 24-Jul-2014 14:48:42.481 notify: info: client 192.168.2.251#61865: view
 vi_local_resolver: received notify for zone '250.168.192.in-addr.arpa'
 24-Jul-2014 14:48:42.481 general: info: master 192.168.2.251#53 (source
 192.168.2.252#0) deleted from unreachable cache
 24-Jul-2014 14:48:42.482 general: debug 1: queue_soa_query: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
 24-Jul-2014 14:48:42.482 general: debug 1: soa_query: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
 24-Jul-2014 14:48:42.482 general: debug 3: dns_request_createvia
 24-Jul-2014 14:48:42.482 general: debug 3: request_render
 24-Jul-2014 14:48:42.482 general: debug 3: requestmgr_attach: 0x801f11170:
 eref 1 iref 1
 24-Jul-2014 14:48:42.482 general: debug 3: mgr_gethash
 24-Jul-2014 14:48:42.482 general: debug 3: req_send: request 0x8037eaea8
 24-Jul-2014 14:48:42.482 general: debug 3: dns_request_createvia: request
 0x8037eaea8
 24-Jul-2014 14:48:42.482 general: debug 3: req_senddone: request
 0x8037eaea8
 24-Jul-2014 14:48:42.483 general: debug 3: req_response: request
 0x8037eaea8: success
 24-Jul-2014 14:48:42.483 general: debug 3: req_cancel: request 0x8037eaea8
 24-Jul-2014 14:48:42.483 general: debug 3: req_sendevent: request
 0x8037eaea8
 24-Jul-2014 14:48:42.483 general: debug 1: refresh_callback: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
 24-Jul-2014 14:48:42.483 general: debug 3: dns_request_getresponse:
 request 0x8037eaea8
 24-Jul-2014 14:48:42.483 general: debug 1: refresh_callback: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: serial: new 2014072417, old
 2014070617
 24-Jul-2014 14:48:42.483 general: debug 3: dns_request_destroy: request
 0x8037eaea8
 24-Jul-2014 14:48:42.483 general: debug 3: req_destroy: request 0x8037eaea8
 24-Jul-2014 14:48:42.483 general: debug 3: requestmgr_detach: 0x801f11170:
 eref 1 iref 0
 24-Jul-2014 14:48:42.483 general: debug 1: queue_xfrin: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
 24-Jul-2014 14:48:42.484 general: info: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: Transfer started.
 24-Jul-2014 14:48:42.484 general: debug 1: zone
 250.168.192.in-addr.arpa/IN/vi_local_resolver: requesting IXFR from
 192.168.2.251#53
 24-Jul-2014 14:48:42.484 xfer-in: info: transfer of
 '250.168.192

Re: stub zones

[John Miller]

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


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

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


John


On 06/02/2014 04:52 PM, Nex6|Bill wrote:

so, stub zones allow you to point a zone to a different name server, and
that name-server; to recurse to get the records for that zone. why? why
not let DNS work the way it is suppose to and let your name servers work
for you to the authoritative name-server to get the records? unless,
your changing the zone records, which is why most people I know use it
for, which is evil :)

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


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



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

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

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

John




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

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

correct? thoughts?

-Nex6



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

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




--
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu mailto:johnm...@brandeis.edu



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

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

Re: stub zones

[John Miller]

So... without stub zones, you know the drill: your local resolver follows
delegation, starting from the root nameservers.  Delegation happens, and
life is good.  If you're running views, then things work fine as well: your
view just needs to be configured to allow queries from your local resolvers.

Let's say you're testing out a new set of authoritative DNS servers for
your domain.  These are authoritative-only nameservers (not necessarily
BIND, either: plenty of other software and cloud services out there).  You
want your local resolvers to not follow the usual delegation process: you
want them to begin delegation with your authoritative NSs.

From my experience, the biggest difference between stub zones and forward
zones is that with stub zones, the RD bit is unset--it's up to the local
resolver to follow delegation, starting with the nameservers configured in
the stub zone, rather than starting with the root NS.

With forwarders, the RD bit is unchanged--you can easily end up sending
recursive queries to a server that isn't set up to handle them.  You might
also end up not getting a full answer to your query: the forwarder
destination isn't doing recursion, so your answer will only be one level
deep.

John


On Mon, Jun 2, 2014 at 5:37 PM, Nex6|Bill n6gh...@yahoo.com wrote:

 I guess, i am having issues with this(maybe i am not fully getting it),
 and yea I know large environments sometimes have multiple sets of name
 servers. sometimes department level (i have this issue in my shop its a
 damn mess)

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

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




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



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

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

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

 John


 On 06/02/2014 04:52 PM, Nex6|Bill wrote:
  so, stub zones allow you to point a zone to a different name server, and
  that name-server; to recurse to get the records for that zone. why? why
  not let DNS work the way it is suppose to and let your name servers work
  for you to the authoritative name-server to get the records? unless,
  your changing the zone records, which is why most people I know use it
  for, which is evil :)
 
  its almost the same, as creating a local zone for something your not
  authoritative for and then having to maintain those records. but, i
  guess their may be cases where it may be useful  i guess
 
 
  On Monday, June 2, 2014 1:33 PM, John Miller johnm...@brandeis.edu
 wrote:
 
 
 
 Evil?  Seems a bit strong.  Unusual?  Use with caution?  OK.
 
 Stub zones mean that you're using a different set of authoritative
 nameservers for a particular domain.  You're not storing all of that
 domain's records, except through the usual caching process.  If it's
 a domain you control, where's the harm?
 
 Also, let's say that you're nominally a caching-only nameserver.
 You're responsible for making iterative queries, and you do not want
 the RD bit set.  AFAIK, stub zones are the way to accomplish that.
 Forward zones just pass recursive queries on to someplace else.
 
 John
 
 
 
 
 On Mon, Jun 2, 2014 at 4:02 PM, Nex6|Bill n6gh...@yahoo.com
 mailto:n6gh...@yahoo.com wrote:
 
 recently, a question came up about stub zones came up and what
 they are and are they part of the DNS standards or are they a
 good idea. i said, they are evil and should not be used if you
 can avoid it.  they way I understand them is the are when you
 create local zones for zones you are NOT authoritative for. and;
 the records in the stub zone do not update when the
 authoritative NS does.
 
 correct? thoughts?
 
 -Nex6

Re: Reply Code 0x8083 vs 0x8080

[John Miller]

Hi Jiann-Ming,

Hopefully someone else didn't beat me to the reply.

No such name is an NXDOMAIN response.  It occurs when there are no
records for a given name.  For example, if you query

fasdf---sadfasdfasdf.com

(I hope this doesn't actually exist ;-)

you'll get a No such name/NXDOMAIN response.

No error is normal--the name exists; there may or not be resource records
of the type you're looking for.

For example, querying

example.com SRV

will return No error if there are A records for example.com--even if
there are no SRV records.  So will querying

example.com A.

Perhaps if you can post the name you want to query, the actual queries your
app makes (packet capture is helpful) and the relevant records in the zone,
we can be of more assistance.

John


On Thu, May 29, 2014 at 2:40 PM, Jiann-Ming Su su_...@yahoo.com wrote:

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

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

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

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

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




-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Book recomendations?

[John Miller]

Agreed that _DNS and BIND_ is the first place to start.  After that, two
books I've liked are Jan-Piet Mens' _Alternative DNS Servers_ (free at
http://mens.de/:/altdnsbook) and Ron Aitchison's _Pro DNS and BIND_ (both
versions).  The latter is probably the most current book out there at the
moment.

John


On Tue, May 27, 2014 at 7:23 PM, Warren Kumari war...@kumari.net wrote:

 On Tue, May 27, 2014 at 6:51 PM, Baird, Josh jba...@follett.com wrote:
  Hi,
 
  Can someone recommend a modern/new-ish book on DNS (specifically BIND)?
  I know there have been several O'Reily books throughout the years, but
 haven't kept up on anything in the past few years.  I'm looking for
 architecture design, best practices in designing enterprise and service
 provider DNS architectures, etc.

 Yeah, the DNS and BIND
 (
 http://www.amazon.com/DNS-BIND-Cricket-Liu-ebook/dp/B0026OR2QS/ref=sr_1_1?ie=UTF8qid=1401232807sr=8-1keywords=cricket+liu
 )
 DNS and BIND cookbook
 (
 http://www.amazon.com/DNS-Bind-Cookbook-Cricket-Liu-ebook/dp/B004VB3VFK/ref=sr_1_4?ie=UTF8qid=1401232883sr=8-4keywords=cricket+liu
 )
 and
 DNS and BIND on IPv6 O'Reily books are all still good and relevant...

 As Andrew says, the included ARM is good, but the O'Reily ones above
 are more readable and cover more design type things (IMO)

 W



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




-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: GSS-TSIG updates from Windows clients

[John Miller]

Thanks to both Mark and Nicholas for the help.  Unfortunately, still not 
able to get this working (BIND 9.8.2 (RHEL 6)  AD 2008R2).  It's a case 
of AD negotiating a TKEY (successfully), then reverting back to unsigned 
updates.  If an update's not signed, doesn't matter what your 
update-policy statements look like.


We're just going to continue with unsigned updates (or manual-only 
updates).  I'd still like to solve the problem, but probably won't go 
into production with it.


Some possible insight in the comments of:

http://netlinxinc.com/netlinx-blog/45-dns/136-how-to-implement-gss-tsig-on-isc-bind.html

Windows 7 and Windows 2008 R2 have changed their behavior in regards to 
dynamic updates and how they send signed updates to BIND DNS servers. 
These new operating systems will first send an “unsigned” update to a 
DNS server and will only revert to a “signed” update if there is 
additional information provided in the response DNS message. Earlier 
operating systems would automatically revert to signed updates as the 
next sequence in the dynamic update process. Current versions of BIND 9 
do not place the additional header information in the response package, 
so the Windows 7 and 2008 servers will not revert. There is a patch that 
you can apply (manually) and re-compile that works.


Evidently AD expects additional records in the TKEY response, otherwise 
we see the behavior I'm seeing.  I've attached a pcap of a sample TKEY 
response and a sample unsigned update rejection; if any of you have this 
working, would you mind listing your BIND and AD versions, as well as 
posting some sample packet output?  I'd be curious to see how our 
environment differs from yours.


John



On 05/06/2014 10:15 AM, Nicholas F Miller wrote:

You might try changing your update-policy from:

grant johnmill-dnst...@lab.brandeis.edu zonesub ANY;
grant * zonesub ANY;

to

grant johnmill-dnst...@lab.brandeis.edu zonesub ANY;
grant LAB.BRANDEIS.EDU zonesub ANY;

I’m not positive this is the proper syntax since we don’t use the zonesub 
option. We use the ms-subdomain and krb5-subdomain options:

grant LAB.BRANDEIS.EDU ms-subdomain LAB.BRANDEIS.EDU;
grant LAB.BRANDEIS.EDU krb5-subdomain LAB.BRANDEIS.EDU;

_
Nicholas Miller, OIT, University of Colorado at Boulder



tkey_no_addl.pcap
Description: application/vnd.tcpdump.pcap


update_refused.pcap
Description: application/vnd.tcpdump.pcap
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

GSS-TSIG updates from Windows clients

[John Miller]

/IN' approved
named[13861]: client 129.64.99.24#21999: send
named[13861]: client 129.64.99.24#21999: sendto
named[13861]: client 129.64.99.24#21999: senddone
named[13861]: client 129.64.99.24#21999: next
named[13861]: client 129.64.99.24#21999: endrequest
named[13861]: client @0x7f75640f6980: udprecv
named[13861]: client 129.64.102.112#63504: UDP request
named[13861]: client 129.64.102.112#63504: using view '_default'
named[13861]: client 129.64.102.112#63504: request is not signed
named[13861]: client 129.64.102.112#63504: recursion not available
named[13861]: client 129.64.102.112#63504: update
named[13861]: client 129.64.102.112#63504: update '_
msdcs.lab.brandeis.edu/IN' denied
named[13861]: client 129.64.102.112#63504: send
named[13861]: client 129.64.102.112#63504: sendto
named[13861]: client 129.64.102.112#63504: senddone
named[13861]: client 129.64.102.112#63504: next
named[13861]: client 129.64.102.112#63504: endrequest

Contrast this with logs from a successful update (from my desktop):

named[12766]: client 129.64.8.232#56297: UDP request
named[12766]: client 129.64.8.232#56297: using view '_default'
named[12766]: client 129.64.8.232#56297: request is not signed
named[12766]: client 129.64.8.232#56297: recursion not available
named[12766]: client 129.64.8.232#56297: query
named[12766]: client 129.64.8.232#56297: query '_
msdcs.lab.brandeis.edu/SOA/IN' approved
named[12766]: client 129.64.8.232#56297: send
named[12766]: client 129.64.8.232#56297: sendto
named[12766]: client 129.64.8.232#56297: senddone
named[12766]: client 129.64.8.232#56297: next
named[12766]: client 129.64.8.232#56297: endrequest
named[12766]: client @0x7f51a80f6980: udprecv
named[12766]: client 129.64.8.232#34226: new TCP connection
named[12766]: client 129.64.8.232#34226: replace
named[12766]: clientmgr @0x7f51a8004f98: createclients
named[12766]: clientmgr @0x7f51a8004f98: recycle
named[12766]: client 129.64.8.232#34226: read
named[12766]: client 129.64.8.232#34226: TCP request
named[12766]: client 129.64.8.232#34226: using view '_default'
named[12766]: client 129.64.8.232#34226: request is not signed
named[12766]: client 129.64.8.232#34226: recursion not available
named[12766]: client 129.64.8.232#34226: query
named[12766]: failed gss_inquire_cred: GSSAPI error: Major = Unspecified
GSS failure.  Minor code may provide more information,
Minor = Success.
named[12766]: gss-api source name (accept) is
johnmill-dnst...@lab.brandeis.edu
named[12766]: process_gsstkey(): dns_tsigerror_noerror
named[12766]: client 129.64.8.232#34226: send
named[12766]: client 129.64.8.232#34226: sendto
named[12766]: client 129.64.8.232#34226: senddone
named[12766]: client 129.64.8.232#34226: next
named[12766]: client 129.64.8.232#34226: endrequest
named[12766]: client 129.64.8.232#34226: read
named[12766]: client @0x7f51a847c120: accept
named[12766]: client 129.64.8.232#34226: next
named[12766]: client 129.64.8.232#34226: request failed: end of file
named[12766]: client 129.64.8.232#34226: endrequest
named[12766]: client 129.64.8.232#34226: closetcp
named[12766]: client 129.64.8.232#49802: new TCP connection
named[12766]: client 129.64.8.232#49802: replace
named[12766]: clientmgr @0x7f51a8004f98: createclients
named[12766]: clientmgr @0x7f51a8004f98: recycle
named[12766]: client 129.64.8.232#49802: read
named[12766]: client 129.64.8.232#49802: TCP request
named[12766]: client 129.64.8.232#49802: using view '_default'
named[12766]: client 129.64.8.232#49802: request has valid signature:
johnmill-dnstest\@LAB.BRANDEIS.EDU
named[12766]: client 129.64.8.232#49802: recursion not available
named[12766]: client 129.64.8.232#49802: update
named[12766]: client @0x7f51a8104b70: accept
named[12766]: client 129.64.8.232#49802: updating zone '_
msdcs.lab.brandeis.edu/IN': adding an RR at 'yourmom._msdcs.lab.brandeis.edu'
A
named[12766]: client 129.64.8.232#49802: send
named[12766]: client 129.64.8.232#49802: sendto
named[12766]: client 129.64.8.232#49802: senddone
named[12766]: client 129.64.8.232#49802: next

Even though it sends valid TKEY credentials, why doesn't Windows actually
sign its updates or use a TCP connection for them?  Any way to actually get
the Windows side of things to send signed updates?

John

-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Forwarding request to another DNS server but the same domain

[John Miller]

Hi Jeronimo,

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

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

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

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

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

What exactly are you trying to achieve?

John



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

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

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

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

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

 Thanks a lot,

 JeLo


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

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




-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Forwarding request to another DNS server but the same domain

[John Miller]

First of all, unless you need separate views for each office, don't go down
that path.  Why are you attempting this as opposed to standard master-slave
replication?

There's something else I'm not understanding here: why would recursive
queries from one office go to the other office's nameservers?  What's
preventing you from setting up a second recursive nameserver in each office?

John



On Wed, Apr 30, 2014 at 4:32 PM, Jeronimo L. Cabral jelocab...@gmail.comwrote:

 Dear John, this is my scenario:

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

 So both office have a different master zone.

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

 Thanks again, regards.

 JeLo



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

 Hi Jeronimo,

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

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

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

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

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

 What exactly are you trying to achieve?

 John



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

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

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

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

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

 Thanks a lot,

 JeLo


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

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




 --
 John Miller
 Systems Engineer
 Brandeis University
 johnm...@brandeis.edu
 (781) 736-4619

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

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





-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Dig for a reverse zone transfer

[John Miller]

Hi Roberto,

Yep, that should do it.

John


On Tue, Apr 22, 2014 at 4:11 PM, Roberto Carna robertocarn...@gmail.comwrote:

 Dear, what are the dig syntaxis in order to get a reverse zone
 transfer from a DNS server ???

 is this correct:

 dig @name of DNS 1.168.192.in-addr.arpa axfr

 Thanks a lot !!!

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

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




-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Can Master replicate zone options in Slave's named.conf.local file ???

[John Miller]

Hi Roberto,

For cases like this, where only a couple of parameters are different, a
configuration management system like Chef, Saltstack, or Puppet really
comes in handy.  You copy things by hand when you're just tinkering around,
but as soon as you're reasonably sure about things, into config management
it goes.

John


On Wed, Apr 16, 2014 at 1:53 PM, Roberto Carna robertocarn...@gmail.comwrote:

 OK Jeff, thanksso the only way to write these bottom lines in the
 Slave is by hand (except if use scp or something similar)???

 zone company.com {
 type slave;
 file /etc/bind/zones/company.com.db;
 allow-transfer { key company; };
 }

 Bind per se can't do it ???


 Thanks again.

 2014-04-16 14:37 GMT-03:00 Lightner, Jeff jlight...@dsservices.com:
  The slave should have different info such as the type being slave
 rather than master
   e.g.
 
  zone company.com {
  type slave;
  file /etc/bind/zones/company.com.db;
  allow-transfer { key company; };
  };
 
  Also if you were allowing by IP rather than acl you might need to change
 the transfer options.   Others might apply as well.
 
  I always do it by hand but it would probably be easy enough to script
 using an sftp and sed on UNIX/Linux.
 
 
 
 
 
 
 
  -Original Message-
  From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:
 bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of
 Roberto Carna
  Sent: Wednesday, April 16, 2014 1:24 PM
  To: bind-users@lists.isc.org
  Subject: Can Master replicate zone options in Slave's named.conf.local
 file ???
 
  People, I have a Master / Slave BIND9 system.
 
  When I add a new zone to the Master and set it up in named.conf.local
 file as follow:
 
  zone company.com {
  type master;
  file /etc/bind/zones/company.com.db;
  allow-transfer { key company; };
  };
 
  Can Master write these options to Slave's named.conf.local file and
 order to reload its config ???
 
  Or do I always have to write by hand these options in Slave's
 named.conf.local and after that restart the bind9 daemon ???
 
  Thanks a lot.
 
  Roberto
  ___
  Please visit https://lists.isc.org/mailman/listinfo/bind-users to
 unsubscribe from this list
 
  bind-users mailing list
  bind-users@lists.isc.org
  https://lists.isc.org/mailman/listinfo/bind-users
 
 
 
 
  Athena(r), Created for the Cause(tm)
  Making a Difference in the Fight Against Breast Cancer
 
  -
  CONFIDENTIALITY NOTICE: This e-mail may contain privileged or
 confidential information and is for the sole use of the intended
 recipient(s). If you are not the intended recipient, any disclosure,
 copying, distribution, or use of the contents of this information is
 prohibited and may be unlawful. If you have received this electronic
 transmission in error, please reply immediately to the sender that you have
 received the message in error, and delete it. Thank you.
  --
 
 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to
 unsubscribe from this list

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




-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: how to modify the cache

[John Miller]

Are you trying to override the IP address locally, or are you just trying
to get the correct value into cache?

John


On Fri, Feb 14, 2014 at 8:52 AM, houguanghua houguang...@hotmail.comwrote:

 Hi all,
 Bind provides rndc tools to operate the cache. But how to change a record
 in the cache. For example:
 to modify origin record  *www.abc.com* http://www.abc.com/* A IN
 219.142.3.1 * into *www abc.com http://abc.com A IN 143.3.1.20*.
 I just know that using rndc flush to clear the cache, but don't know how
 to modify the cache.

 Who can tell me how to do?Thanks.
 Guanghua

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

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




-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DNS passthrough on no explicit result?

[John Miller]

On Fri, Jan 31, 2014 at 11:10 AM, Steve Presser st...@pressers.name wrote:

 Hey all,
 Please forgive me if any of my terminology is off - I have not spent as
 much time in the  documentation as I'd like.
 I have an odd situation that I would like to know if it is possible and
 would much appreciate a pointer to any relevant  documentation or write-ups.
 I manage a domain name which, for reasons of reliability, uses an
 externally managed DNS server (zoneedit). We're looking to add private
 network DNS for internal machines. I've got BIND up and running on an
 internal machine. However, we have public records that need to be
 accessible internally (SPF, DKMS, jabber servers, MXs, etc). Additionally,
 using an internal-only namespace is not an option, due to laptops which go
 in and out of the network and need to be able to connect without settings
 modification.
 I'm trying to figure out how to do some sort of pass through  arrangement,
 where the internal BIND server will first attempt to do the lookup with
 local records. If it has no local record, it will then fall back to the
 answer returned by the external (zoneedit) server.
 I know that if there was only one server, this would simply be split
 horizon. However, I don't know what to call this setup, and am having a
 hard time searching for it because of that. (So I apologize if this is then
 a dumb question).

 Any help you can offer is much appreciated. Thanks!
 Steve


Hi Steve,

I'm afraid I'm not following you here.  You have records which absolutely
need to be public: SPF, MXs--mail won't work otherwise.  Do you want your
DKMS and jabber records to be internal-only, or can they be public as well?

If everything can be public, why the question?  If you want internal-only
records, why not just do split horizon of some sort where you use zoneedit
as a slave and your local BIND view as a master?  That way you have two
views, one for internal IPs, and one for external IPs.

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

Re: DNS passthrough on no explicit result?

[John Miller]

On Fri, Jan 31, 2014 at 12:41 PM, Vernon Schryver v...@rhyolite.com wrote:

  You have records which absolutely
  need to be public: SPF, MXs--mail won't work otherwise.

 I hope I misunderstood the intended meaning or context of those words,
 because their literal, context free meaning that SPF and MX records
 are required by SMTP is wrong.

 SPF might be considered required by unsolicited or semi-solicited
 bulk mail senders to help large scale free mailbox providers gauge
 the legitimacy of mail advertisements.  Otherwise SPF is *not*
 required.  As proof consider both this message and the DCC mailing
 lists (i.e. old school solicited bulk mail.)  In some cases SPF
 harms SMTP delivery, especially when combined with DMARC.

 Because I'm in neither the email advertising business nor the large
 scale free mailbox businesses, the only unambiguous use I've found
 for SPF records is to try to prevent mail.  I publish SPF RRs for some
 domains that send no mail in order to reduce NDRs or bounces of
 forged mail from bad SMTP servers (mail receivers) that fail to validate
 SMTP Rcpt_To values during the SMTP transaction.


 The case for MX records being required for SMTP is clear.  In the
 absense of an explicit MX record, the standards require SMTP clients
 (mail senders) to infer an implicit MX from derived A or  records.


 Vernon Schryverv...@rhyolite.com



Indeed, the intent of my words was that SPF only makes sense if it's
public--presumably you set up trust between your internal mail servers in
other ways.  It's not required for SMTP to work--plenty of domains don't
use it.

Thank you for the correction, Vernon.

John

-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
___
Please visit https://lists.isc.org/mailman/listinfo/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: DDNS update forwarding

[John Miller]

On 12/11/2013 08:42 PM, Mark Andrews wrote:

In message 52a8e44a.1070...@brandeis.edu, John Miller writes:

Hello folks,

I'm getting ready to revamp our dynamic DNS setup here on campus, and am
curious: what is everyone doing for update forwarding?  Have you seen
certain clients that will send updates based on NS records rather than
the SOA record?


Which is what the update protocol specifies as the default destination
to send requests to.


Perhaps a better question is: has anyone been bitten by leaving update
forwarding disabled?


If you have a hidden master and clients that follow the RFC and
send to the nameservers then you will need to enable update forwarding.
The exact condfiguration depends on how you are authenticating
updates for the zone.  If it is by IP address you will need to
configure the update forwarding server to use a similar acl.  If
you are using TSIG then you can just forward all update requests.

If is off by default as it is the only safe configuration when you
don't know how the master is configured not because one shouldn't
forward update requests.

Mark


Thanks, Mark.  Exactly what I wanted to know.  We're using TSIG on our 
master, so no reason _not_ to forward update requests.


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

DDNS update forwarding

[John Miller]

Hello folks,

I'm getting ready to revamp our dynamic DNS setup here on campus, and am 
curious: what is everyone doing for update forwarding?  Have you seen 
certain clients that will send updates based on NS records rather than 
the SOA record?


Perhaps a better question is: has anyone been bitten by leaving update 
forwarding disabled?


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

Re: how-to configure BIND or any DNS implementation for cloud infrastructure

[John Miller]

Hi David,

Cloud DNS is not only possible, but desirable in many cases.  A large
anycasted provider can provide better latency and availability than most
organizations.

If you're looking for a hosted DNS solution, most will accept NOTIFY
packets from a BIND instance.  If you're just looking to run a nameserver
hosted in EC2/Rackspace/etc., you can install whatever DNS server you
like--you're managing the box yourself.

John


On Fri, Aug 30, 2013 at 12:01 PM, Odimegwu David odimegwuda...@yahoo.frwrote:

 Is it possible for one to configure BIND or any DNS implementation for the
 cloud?
 I was forced to search for this forum because the exigences of my
 situation necessitates a cloud. But yet, in a cloud:
 1. I cannot be systems administrator, even if, I don't know yet, if the
 company can give me administrator privileges.
 2. The IP address of the machine will not possibly be my own because the
 machine will be shared by numerous subscribers to the cloud infrastructure.
 3. I know that like all other users, i will be given set of user
 privileges that are restrictive.
 So, i am doubtful if my intentions are possible?
 Although, the domain name and zone administration recourses to me.
 With this constraints, is it possible for cloud DNS to be possible? I have
 this site in mind: polarhome.com, where i intend paying for server space.
 thanks
 odimegwu 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




-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: ISO or virtual appliance

[John Miller]

Hi Manish,

You can always grab a pre-canned ISO from turnkeylinux.org.  You could 
also use Puppet or Chef recipes to get BIND up and running.  I'm sure 
someone also has a Vagrant box available -- try vagrantbox.es.


Generally speaking, though, if you're using an appliance in production, 
you need to understand the innards and be prepared to do your own 
maintenance, or you need to pay someone for support.


John


On 08/21/2013 02:34 PM, Manish Rane wrote:

Hi Guys,

Is there any ISO or virtual appliance available for BIND? Which ease out
the deploy and configuration task.



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

RFC requirements for relative CNAME targets?

[John Miller]

Hey there folks,

I know that for the following record in a zone file:

host.example.com.

-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: RFC requirements for relative CNAME targets?

[John Miller]

My apologies--sent mid-message!

I know that for the following record in example.com's zone file:

host.example.com.  IN CNAME otherhost

BIND will return:

host.example.com. TTL IN CNAME otherhost.example.com.

Is this behavior required anywhere in the RFCs, or would

host.example.com. TTL IN CNAME otherhost.

be equally valid from an RFC perspective?  Obviously this would also
pertain to NS, MX, SRV, PTR, etc. records.

John


On Thu, Jul 18, 2013 at 4:12 PM, John Miller johnm...@brandeis.edu wrote:

 Hey there folks,

 I know that for the following record in a zone file:

 host.example.com.

 --
 John Miller
 Systems Engineer
 Brandeis University
 johnm...@brandeis.edu
 (781) 736-4619

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

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

Re: RFC requirements for relative CNAME targets?

[John Miller]

On Thu, Jul 18, 2013 at 4:29 PM, Charles Swiger cswi...@mac.com wrote:

 On Jul 18, 2013, at 1:18 PM, John Miller johnm...@brandeis.edu wrote:
  I know that for the following record in example.com's zone file:
 
  host.example.com.  IN CNAME otherhost
 
  BIND will return:
 
  host.example.com. TTL IN CNAME otherhost.example.com.

 Assuming $ORIGIN is set to example.com, but yes.

  Is this behavior required anywhere in the RFCs, or would
 
  host.example.com. TTL IN CNAME otherhost.
 
  be equally valid from an RFC perspective?  Obviously this would also
 pertain to NS, MX, SRV, PTR, etc. records.

 otherhost. is equally valid from an RFC perspective, or
 otherhost.other.domain.  If there is a trailing dot, the CNAME target is
 assumed to be fully qualified, otherwise $ORIGIN is appended just as it
 would be for any other record using an unqualified name.

 Regards,
 --
 -Chuck


I think what I was getting at was whether appending $ORIGIN to an
unqualified target--only talking target, not label--was _required_ by the
RFCs, and if so, the RFC/section.  I'll read through 'em; was just hoping
someone knew the answer off the top of their head.

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

Re: RFC requirements for relative CNAME targets?

[John Miller]

Hi Ryan,

Sorry I wasn't more clear in my original post.  Barry hit the nail on 
the head:  I was curious if the RFCs required BIND to append $ORIGIN to 
targets that aren't fully qualified.  Sounds like they do.


I appreciate the help!

John



On 07/18/2013 05:59 PM, Novosielski, Ryan wrote:

Are you asking if the target of a CNAME need be an FQDN if $ORIGIN is
defined? If so, no, I use short names (no trailing dot) all the time.


*From*: John Miller [mailto:johnm...@brandeis.edu]
*Sent*: Thursday, July 18, 2013 05:49 PM
*To*: Bind Users Mailing List bind-users@lists.isc.org
*Subject*: Re: RFC requirements for relative CNAME targets?


On Thu, Jul 18, 2013 at 4:29 PM, Charles Swiger cswi...@mac.com
mailto:cswi...@mac.com wrote:

On Jul 18, 2013, at 1:18 PM, John Miller johnm...@brandeis.edu
mailto:johnm...@brandeis.edu wrote:
  I know that for the following record in example.com
http://example.com's zone file:
 
  host.example.com http://host.example.com.  IN CNAME otherhost
 
  BIND will return:
 
  host.example.com http://host.example.com. TTL IN CNAME
otherhost.example.com http://otherhost.example.com.

Assuming $ORIGIN is set to example.com http://example.com, but yes.

  Is this behavior required anywhere in the RFCs, or would
 
  host.example.com http://host.example.com. TTL IN CNAME otherhost.
 
  be equally valid from an RFC perspective?  Obviously this would
also pertain to NS, MX, SRV, PTR, etc. records.

otherhost. is equally valid from an RFC perspective, or
otherhost.other.domain.  If there is a trailing dot, the CNAME
target is assumed to be fully qualified, otherwise $ORIGIN is
appended just as it would be for any other record using an
unqualified name.

Regards,
--
-Chuck


I think what I was getting at was whether appending $ORIGIN to an
unqualified target--only talking target, not label--was _required_ by
the RFCs, and if so, the RFC/section.  I'll read through 'em; was just
hoping someone knew the answer off the top of their head.

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

Re: RFC requirements for relative CNAME targets?

[John Miller]

On 07/18/2013 06:07 PM, Barry Margolin wrote:

In article mailman.844.1374184195.20661.bind-us...@lists.isc.org,
  John Miller johnm...@brandeis.edu wrote:


I think what I was getting at was whether appending $ORIGIN to an
unqualified target--only talking target, not label--was _required_ by the
RFCs, and if so, the RFC/section.  I'll read through 'em; was just hoping
someone knew the answer off the top of their head.


All names in a zone file that do not end with . get the $ORIGIN
appended to them. This is required by the zone file specification.



Thanks to everyone for their help with this.  You also spurred me to dig 
into RFC 1034/1035 a bit more deeply than I'd done in the past.  Not as 
painful as I'd feared.


From RFC 1035, Section 5.1:
Domain names which do not end in a dot are called relative; the actual 
domain name is the concatenation of the relative part with an origin 
specified in a $ORIGIN, $INCLUDE, or as an argument to the master file 
loading routine.  A relative name is an error when no origin is available.


In other words, for any record type that contains a domain name in its 
RDATA section (CNAME, NS, SOA, MX, SRV, etc.), the nameserver must make 
sure that the domain name is either fully qualified, or it must append 
an origin somehow.


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

Re: Secondary DNS question...

[John Miller]

Hi Jeff,

You've pointed out two separate problems (incoming e-mail not coming in 
outgoing e-mail not going out), so some more details about your environment
would probably be useful here:

- are you combining both authoritative and recursive DNS on the same
servers?
- Are you using different MXes for incoming and outgoing e-mail?
- How is name resolution configured on each? For example, are your MXes
running local caching NS?  Are they forwarding to another NS?  What's their
nameserver order?

Not sure if you're posting from the same domain that had the outage, so
won't make any assumptions there.

That said, some general info: outside MXes use authoritative DNS to send to
you; your incoming MX servers use recursive DNS to do any reverse lookups
on sender IPs, to query DNSBLs, and to get SPF/DKIM/DMARC info; outgoing
MXes use recursive DNS to find outside MXes.

John



On Thu, Jun 20, 2013 at 11:02 PM, SH Development 
listacco...@starionline.com wrote:

 Our secondary DNS machine went down (and unnoticed for 24 hours).

 Today, we had multiple people calling about email that hadn't come in, and
 trouble with outgoing emails not going out.

 Our primary DNS was up the whole time.  So my question is, why would my
 secondary being down, and only my primary being up cause so many problems?
  I thought the whole idea behind having two DNS servers on different
 networks was to never have a failure like this.

 My understanding was that when DNS is queried, the one that responds
 fastest is the information that is used.  If the secondary is down, then
 the primary would by default always be fastest (and only).

 I think I reasonably understand basic DNS and the setup, but this has me
 thinking that something isn't set up right.

 Can anyone shed any light on what might have happened here?  Could my
 primary not be responding as it should?  All the tests I have run on it
 show that it is responding normally.

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

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




-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: PTR files

[John Miller]

Norman,

Everyone who's posted has probably been correct--this doesn't look like
_either_ an httpd or BIND problem, but rather in general name resolution
and perhaps in how you've configured things.  Happy to assist off-list (see
separate cover), but let's leave it there until it's clear that your issue
is with BIND and how you've configured it.

John





On Mon, Jun 17, 2013 at 11:37 PM, Doug Barton do...@dougbarton.us wrote:

 Norman,

 It's virtually certain that the error you're seeing is not related to
 BIND. You would almost certainly get your problem solved faster by posting
 on a list related to the web server software that you are using and walking
 through your complete configuration with them.

 Good luck,

 Doug

 __**_
 Please visit 
 https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-usersto
  unsubscribe from this list

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




-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
(781) 736-4619
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Queries using forwarders

[John Miller]

Hi Mike,

To keep my answer simple, if BIND is set up to allow recursion, and gets 
a recursive query for a zone it's not authoritative for, it'll:


1) Answer from cache
2) pass the query off to the configured forwarders
3) If the forwarders are unavailable, follow delegation itself to answer 
the query.


BIND is only authoritative for a zone if there's a

zone {}

block for it (or its parent zone).

As Steven mentioned, you can set BIND up to act as authoritative for a 
domain you don't own (e.g. malware.site.tld) so that your users get a 
false answer to their queries.  It's a pretty common 
anti-malware/anti-spam practice, and also gets used (for example) in 
wifi captive portals.


John

On 06/03/2013 03:36 PM, Ward, Mike S wrote:

Hello all, I was trying to follow the thread on the NXDOMAIN and got lost. :) I 
have a question about using forwarders. If the DNS that is using forwarders 
receives a query for a zone it's not authoritative for even if it's in the same 
network, does it go to the forwarders for zone information? I'm trying to get 
my head around what was discussed in the NXDOMAIN thread. What makes a DNS 
authoritative for a zone?

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.
___
Please visit https://lists.isc.org/mailman/listinfo/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: This didn't work....

[John Miller]

 Probably should've wrote that is the first case it was:

 $ORIGIN foo.example.com.
 ...
 ads  NS  ads.foo.example.com.
 ...
 ads  A   a.b.c.d
 dc2  A   a.b.c.e
 dc3  A   a.b.c.f

 And, the modified case was:

 $ORIGIN foo.example.com
 ...
 ads  NS  dc2.foo.example.com.
  NS  dc3.foo.example.com.
 ...
 ads  A   a.b.c.d
 dc2  A   a.b.c.e
 dc3  A   a.b.c.f


Okay--that helps.



 I didn't add dc2 or dc3...they were that way.  And, they said those are
 their primary and secondary ADS servers.

 But, the nameserver for (sub)domain can be anywhereincluding in
 somebody else's domain


Sure can.  But AD domain controllers are generally located within their own
domain.  I don't know enough about AD to tell you what would happen if
someone put their domain controllers in another domain, but my guess is
that there would be problems


 ksu.edu's NS's are ns-1.ksu.edu, ns-2.ksu.edu, ns-3.ksu.edu,
 nic.kanren.net, and kic.kanren.net.  The registrar has the IP address of
 ns-1.ksu.edu, ns-2.ksu.edu and ns-3.ksu.edu, so that it can included in
 the additional section when their resolvers are hit


Makes sense -- the .edu folks need to have your glue records.


 And, its certain possible that the hosts true FQDN is
 dc2.ads.foo.example.com, but they had put them into central DNS as
 dc2.foo.example.com, before they had started doing ADS.  It could also be
 something else entirely...like bob.ads.foo.example.com.


At this point, I'd forget about whatever they originally put into central
DNS and just approach this fresh.


 In fact, when I do a dig +trace ads.foo.example.com, I get:

 ads.foo.example.com.  600 IN  A   a.b.c.e
 ads.foo.example.com.  600 IN  A   a.b.c.f
 ads.foo.example.com.  600 IN  A   a.b.c.d
 ads.foo.example.com.  3600IN  NS  dc2.ads.foo.example.com.
 ads.foo.example.com.  3600IN  NS  dc1.ads.foo.example.com.
 ads.foo.example.com.  3600IN  NS  dc3.ads.foo.example.com.
 ads.foo.example.com.  3600IN  SOA dc3.ads.foo.example.com.
 hostmaster. 1334667 900 600 86400 3600


Nice.  This is beginning to make more sense.  Can you post the full dig
+trace output?  Feel free to pm me if you don't feel comfortable posting it
to the list.


 if I ask dc3.ads.foo.example.com what dc3.ads.foo.example.com is, it
 answers a.b.c.f
 if I ask dc3.ads.foo.example.com what dc2.ads.foo.example.com is, it
 answers a.b.c.d and a.b.c.e
 if I ask dc3.ads.foo.example.com what dc1.ads.foo.example.com is, it
 answers a.b.c.g


Perfect.  Confirm that dc1 and dc2 also return the same answers.  It sounds
very much like you need to delegate ads to dc1, dc2, and dc3, plus put in
glue that points dc1 to a.b.c.g, dc2 to a.b.c.d and a.b.c.e, and dc3 to
a.b.c.f:

$ORIGIN ads.foo.example.com.
@ NS dc1.ads.foo.example.com.
@ NS dc2.ads.foo.example.com.
@ NS dc3.ads.foo.example.com.
dc1 A a.b.c.g
dc2 A a.b.c.d
dc2 A a.b.c.e
dc3 A a.b.c.f

And that's all you should list.  No need to create an A record for
ads.foo.example.com -- let their own nameservers handle that.  Hopefully I
understand you correctly that you manage DNS for foo.example.com, and that
ads.foo.example.com is delegated.  If not, please let me know which
subdomains you manage and which the department manages.  It's entirely
possible I've still misunderstood you.


 So, I then tried:

 $ORIGIN ads.foo.example.com
 @  NSdc2
NSdc3
 dc2A a.b.c.e
 dc3A a.b.c.f

 Which didn't help anything


This seems correct, apart from not delegating to dc1 as well, and not
including glue for both of the dc2 IPs.  Any reason not to delegate/glue
dc1 as well?



 Anyways...I guess at this point the problem lies with the ADS setup


Definitely could be.  But make sure your delegation is rock-solid first.
Please post the full output (both A and NS queries) of your normal dig
queries for ads.foo.example.com and your dig +trace ads.foo.example.com.
Please also post your full zone config for foo.example.com and
ads.foo.example.com.  Ok to pm me if you'd rather not post those to the
list.


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

Re: This didn't work....

[John Miller]

Hi Lawrence,

I'm going to answer your questions a bit out of order, but hopefully
things'll still be clear.


 How do you have an AD domain where your AD servers aren't authoritative
 for itself?


This is how our AD domain is set up -- the root of the AD domain is
brandeis.edu, but the domain controllers do not run the MS DNS Server
service.  Client computers get the main campus DNS resolvers via DHCP, and
are set not to use the MS DNS Client service.  We've set up dynamic zones
in BIND for the zones needed by AD: _msdcs.brandeis.edu, _tcp.brandeis.edu,
_udp.brandeis.edu, etc.

Microsoft TechNet has some really thorough docs on this:

http://technet.microsoft.com/en-us/library/dd316373.aspx

It's a bit dated, but the principles still apply.  The more general
Microsoft docs:

http://technet.microsoft.com/en-us/library/cc759550%28v=ws.10%29.aspx
http://technet.microsoft.com/en-us/library/cc772774%28v=ws.10%29.aspx

are also quite good.


Had a strange problem where our servers couldn't resolve hosts in an AD
 subdomain.


Can you clarify the problem a bit here?  Is it that the authoritative
nameservers for foo.example.com are unable to resolve ads.foo.example.com?
Do the foo.example.com servers look to themselves for recursion?  Am I
correct that a department on campus is running their own AD environment
with a root of ads.foo.example.com, and you simply delegate the subdomain
to them?


 This was in the zone file:

  $ORIGIN foo.example.com.
  ...
  ads NS ads.foo.example.com
  ...
  ...
  ...
  ads A  a.b.c.d
  ...
  ...
  ...


This looks pretty normal if you're delegating the ads.foo.example.com zone
to a server called ads.foo.example.com.  A little confusing to use the same
name for the nameserver as the subdomain itself, but it seems like it
should work.

So changing to:

  $ORIGIN foo.example.com
  ...
  ads  NS dc2.foo.example.com.
   NS dc3.foo.example.com.
  dc2  A  a.b.c.e
  dc3  A  a.b.c.f
  ...


This looks very odd indeed.  If the root of the AD domain is
ads.foo.example.com, why do the DCs live in the parent zone?  Is that
something you allow?  The first zone config looked more appropriate.

Without going any further into this, it looks as though the department may
have set their AD domain up as foo.example.com when in reality it should
be ads.foo.example.com.  Can you clarify this?

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

Re: 3rd party CNAMEs and open recursion

[John Miller]

On 03/04/2013 03:26 PM, Verne Britton wrote:

my test server (its up and down a lot) is at yournameserver with these two test 
zones ... what I want to be able to do is:

1. serve the A records as authoritative


Looks like it's working in that regard:

jm@workstation:~$ dig +norecurse @yournameserver wvstateu.edu ns
;; QUESTION SECTION:
;wvstateu.edu.  IN  NS
;; ANSWER SECTION:
wvstateu.edu.   86400   IN  NS  nameserv3.wvnet.edu.

jm@workstation:~$ dig +norecurse @yournameserver wvstateu.edu
;; QUESTION SECTION:
;wvstateu.edu.  IN  A
;; ANSWER SECTION:
wvstateu.edu.   86400   IN  A   98.129.177.93
;; AUTHORITY SECTION:
wvstateu.edu.   86400   IN  NS  nameserv3.wvnet.edu.

jm@workstation:~$ dig +norecurse @yournameserver gmail.wvstateu.edu
;; QUESTION SECTION:
;gmail.wvstateu.edu.IN  A
;; ANSWER SECTION:
gmail.wvstateu.edu. 3600IN  CNAME   ghs.l.google.com.



2. somehow handle resolutions coming at me for the CNAMEs


Looks like that's working; see above.



3. not have a public open recursive server



jm@workstation:~$ dig @yournameserver gmail.com

;; -HEADER- opcode: QUERY, status: REFUSED, id: 23091
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;gmail.com. IN  A


So from my side of things, all of your requirements are being met ;-)

Can you post a copy of your dig command where the server _is_ trying to 
follow up the CNAME resolution?  Based on your config, the server should 
try to follow up the CNAME (answer recursively) for anything in the 
trusted ACL, which includes your server itself.


Some questions:
- What's the overall purpose of this server?  To answer recursive 
queries from internal clients?  To answer authoritative queries from 
internal clients (hidden master)?  To answer authoritative queries from 
the outside world?  Right now, you're doing all three, which isn't 
ideal.  Far better to separate things out.


John



Verne

Verne Britton, Lead Systems Programmer   voice:   (304) 293-5192 x230
Systems Support Group(in WV, call 1-800-253-1558)
West Virginia Network forFAX: (304) 293-5540
  Educational Telecomputing   ve...@wvnet.edu
837 Chestnut Ridge Road  http://myweb.wvnet.edu/~verne
Morgantown, WV  26505http://www.wvnet.edu

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

Resolver behavior on expired TTLs

[John Miller]

Hello everyone,

Here's something I hadn't put much thought into until recently--it's 
never been a problem--how do resolvers behave when they receive a 
request for an expired entry in the cache, but cannot contact the 
authoritative nameserver?  I'd imagine they return a SERVFAIL, but I 
could see NXDOMAIN as well.  Does anyone know the answer?


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

Re: Resolver behavior on expired TTLs

[John Miller]

Thanks, Matus.  Much appreciated--a SERVFAIL is much better than an 
NXDOMAIN in this scenario.


John


On 02/21/2013 10:41 AM, Matus UHLAR - fantomas wrote:

On 21.02.13 10:38, John Miller wrote:

Here's something I hadn't put much thought into until recently--it's
never been a problem--how do resolvers behave when they receive a
request for an expired entry in the cache, but cannot contact the
authoritative nameserver?  I'd imagine they return a SERVFAIL, but I
could see NXDOMAIN as well.  Does anyone know the answer?


they should not sent anything but SERVFAIL if they are unable to do the
resolution. SERVFAIL should cause the client ask other server, while
NXDOMAIN means that the host does not exist and client can stop searching.


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

[John Miller]

Just to cover all the bases, you're doing your lookup directly against 
your server, correct?  Easy to accidentally query a different nameserver 
and not see what you're expecting.


Otherwise I'd second Warren's suggestion to double-check your serial number.

John


On 02/20/2013 12:40 PM, Jsilliman wrote:

I can't seem to create an extra A record that works.  I've created A
records for ns1 and mail and they work if I do a bind lookup, but
nothing else works.  I did a lot of research before reaching out here.
  This is my zone file.   Remote.example.com never works...This is
Bind9 running on Ubuntu server.


Main zone file

;
$TTL604800
@   IN  SOA ns1.example.com. root.example.com. (
   10; Serial
  604800 ; Refresh
   86400 ; Retry
 2419200 ; Expire
  604800 )   ; Negative Cache TTL
;
@   IN  NS  ns1.example.com.
@INMX  10mail.example.com.

;   IN  A   69.62.x.x
;   IN  ::1
;IN SPF v=spf1 ptr -all
;   IN TXT v=spf1 ptr -all

ns1 INA   69.62.x.x

mail INA  69.62.x.x
www  INA  69.62.x.x
remoteIN   A  69.62.x.x

Rev lookup:

; BIND reverse data file for local loopback interface
;
$TTL604800
@   IN  SOA ns1.example.com. example.com. (
   1 ; Serial
  604800 ; Refresh
   86400 ; Retry
 2419200 ; Expire
  604800 )   ; Negative Cache TTL
;
@   IN  NS  ns1.
215 IN  PTR ns1.example.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

Change in statistics format

[John Miller]

Hello everyone,

When did BIND 9 switch over from the older

+++ Statistics Dump +++ (timestamp)
success #
referral #
nxrrset #
nxdomain #
recursion #
failure #
--- Statistics Dump --- (timestamp)

to the newer

+++ Statistics Dump +++ (timestamp)
++ Incoming Requests ++
   x QUERY
++ Incoming Queries ++
   x A
   x NS
   x PTR
   x 
   x SRV
++ Outgoing Queries ++
[View: default]
   x A
   x NS
   x PTR
   x 
   x SRV
[View: _bind]
++ Name Server Statistics ++
   x IPv4 requests received
   x responses sent
   x queries resulted in successful answer
   x queries resulted in non authoritative answer
   x queries resulted in nxrrset
   x queries resulted in NXDOMAIN
   x queries caused recursion
   x duplicate queries received
... etc.?

Is this a tunable parameter?  I didn't think so, but always helps to ask 
before assuming.


I'm getting ready to file a bug for our monitoring software (Hyperic 
HQ), because it only reads the older format, and wanted to be sure I had 
my ducks in a row.


--
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu
___
Please visit https://lists.isc.org/mailman/listinfo/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 in statistics format

[John Miller]

Thanks, Phil.  Those were my thoughts as well.  For the present, I'll 
write my own monitoring plugin to parse the XML data.


John

On 11/15/2012 11:47 AM, Phil Mayers wrote:

On 15/11/12 16:44, John Miller wrote:

Hello everyone,

When did BIND 9 switch over from the older



I think that was *years* ago?


I'm getting ready to file a bug for our monitoring software (Hyperic
HQ), because it only reads the older format, and wanted to be sure I had
my ducks in a row.


You might want to ask them to parse the XML statistics channel, rather
than the human-readable stuff. It's obviously machine-readable, and
contains a *lot* more granular stuff.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list

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

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

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

Re: Change in statistics format

[John Miller]

Thanks, Carsten,

I've opened bug #4619 and indeed asked Hyperic to parse the XML output. 
 I agree, it's much nicer than trying to parse the rndc.stats file!


If anyone here has already written a BIND plugin for Hyperic, let me 
know--I'd love to have a copy and see if it'll work for us.


John


On 11/15/2012 11:58 AM, Carsten Strotmann wrote:


Hello John,

John Miller johnm...@brandeis.edu writes:


Hello everyone,

When did BIND 9 switch over from the older

+++ Statistics Dump +++ (timestamp)
success #
referral #
nxrrset #
nxdomain #
recursion #
failure #
--- Statistics Dump --- (timestamp)

to the newer

+++ Statistics Dump +++ (timestamp)
++ Incoming Requests ++
x QUERY
++ Incoming Queries ++


[...]



I'm getting ready to file a bug for our monitoring software (Hyperic
HQ), because it only reads the older format, and wanted to be sure I
had my ducks in a row.


I'm not sure in which version this change of the output happen, but if
you write a bug report for the monitoring system, you might want to ask
the vendor/developer to also implement an option to parse the BIND
statistics channel output data.

The statistics channel delivers well formed XML, which (in my view) is
much easier to parse compared to the text output produced by rndc
stats. With proper XML parsing, it should also guard against issues in
case the statistics data be expanded in the future.

And as a bonus, there is much more interesting data in the statistics
channel XML.

-- Carsten


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

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