Re: Frequent timeout

[Chuck Swiger via bind-users]

Hi, Alex--

On Aug 31, 2018, at 3:49 PM, Alex  wrote:
> The interface does show some packet loss:
> 
> br0: flags=4163  mtu 1500
> [ ... ]
>RX packets 1610535  bytes 963148307 (918.5 MiB)
>RX errors 0  dropped 5066  overruns 0  frame 0
> 
> Is some packet loss such as the above to be expected? I recall doing
> some network tests some time ago and found much of it was IPv6
> traffic, which is not being used.

0.3% dropped packets is a bit unusual for a NIC running against a switch;
it would be quite normal for a hub.  However, Linux tends to also count
various things like unknown VLAN tags, unknown protocols (ie, IPv6 traffic
on an IPv4-only host), etc as dropped RX packets.

Supposedly ethtool -S helps distinguish between actual interface errors
and traffic that your machine chooses to drop.

Regards,
-- 
-Chuck

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

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

Re: DNS64 & nslookup

[Chuck Swiger]

On Apr 11, 2018, at 4:26 PM, Mark Boolootian  wrote:
>>> As far as I know, a host with on an IPv6 address is only ever
>>> going to perform  lookups.  I'd be very interested to know
>>> if there are cases where that isn't true.
>> 
>> Well, if you run nslookup or dig -t a, you're asking for A records
>> explicitly.
> 
> Ah, true that.  Does nslookup do that by default?

Yes, nslookup has A as the default type.  Here is nslookup handling a  
query:

% nslookup -type= ipv4.l.google.com
Server: 192.168.1.1
Address:192.168.1.1#53

Non-authoritative answer:
*** Can't find ipv4.l.google.com: No answer

Authoritative answers can be found from:
l.google.com
origin = ns1.google.com
mail addr = dns-admin.google.com
serial = 192521433
refresh = 900
retry = 900
expire = 1800
minimum = 60

(If DNS64 was in place, I ought to see 74.125.24.x mapped to an IPv6 address 
instead-- something like 64:ff9b::74.125.24.x.)

Regards,
-- 
-Chuck

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

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

Re: DNS64 & nslookup

[Chuck Swiger]

On Apr 11, 2018, at 3:49 PM, Mark Boolootian  wrote:
> 
>>> I'll give those tools a try, but I don't understand how my client is 
>>> requesting
>> an A record. It only has IPv6 networking. DNS64 should be requesting an
>> A record, but that the client should see is the converted  record. Is 
>> that
>> not right?
>> 
>> Nope-- DNS requests aren't going to convert an A record to a  record.
>> 
>> Normally, IPv6 only machines should request IPv6  records by preference,
> 
> I think he was saying this.  If his machine is truly IPv6-only, then the
> resolver would only perform  lookups (I can't speak to what
> nslookup would do).  That  lookup gets forwarded to the DNS64
> box, which performs the A lookup (and finds no ), and then returns
> the synthesized  record.

Yes.  As Mark A noted, most apps use getaddrinfo()-- with PF_UNSPEC, the system
should ask for A or  records depending on whether IPv4 or IPv6 is preferred.

More sophisticated applications like web browsers tend to have an explicit
search ordering using several getaddrinfo() calls to try both PF_INET and 
PF_INET6,
and pay attention to which address family is getting results or results faster.

>> and fall back to IPv4 A records only when IPv6 isn't available.
> 
> As far as I know, a host with on an IPv6 address is only ever
> going to perform  lookups.  I'd be very interested to know
> if there are cases where that isn't true.

Well, if you run nslookup or dig -t a, you're asking for A records explicitly.

>> However, your   IPv6-only machine will route IPv4 traffic using
>> 6-in-4 or NAT64 addressing,   otherwise you'd get broken
>> connectivity to IPv4-only addresses.
> 
> Not that I'm saying anything you don't know, but that's the
> purpose of DNS64 - to make sure you can reach IPv4 only
> resources.  But if your IPv6-only host is trying to reach an
> IPv4 literal (e.g. embedded in a web page), then unless you
> have a 464 CLAT available, you're out of luck.

OK, fair enough.  If you ask a DNS64 server for an A record, it should still
give you back an A record.  If you ask for an  RR, then you will get back an
 record, even if it has to synthesize an A record into a 6-in-4 IPv6 
address.

Regards,
-- 
-Chuck

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

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

Re: DNS64 & nslookup

[Chuck Swiger]

On Apr 11, 2018, at 3:32 PM, Rick Tillery  wrote:
> I'll give those tools a try, but I don't understand how my client is 
> requesting an A record. It only has IPv6 networking. DNS64 should be 
> requesting an A record, but that the client should see is the converted  
> record. Is that not right?

Nope-- DNS requests aren't going to convert an A record to a  record.

Normally, IPv6 only machines should request IPv6  records by preference, 
and fall back to IPv4 A records only when IPv6 isn't available.  However, your 
IPv6-only machine will route IPv4 traffic using 6-in-4 or NAT64 addressing, 
otherwise you'd get broken connectivity to IPv4-only addresses.

Regards,
-- 
-Chuck

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

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

Re: DNS64 & nslookup

[Chuck Swiger]

On Apr 11, 2018, at 3:09 PM, Rick Tillery  wrote:
> I appear to have my NAT64+DN64 IPv6 -> IPv4 network configured correctly, as 
> I can access IPv4 only Internet sites, e.g. from my browser.  But some tools 
> don't seem to work the way I think they should.
> 
> One example is nslookup.  If do nslookup ipv4.google.com, I get:
> 
> $ nslookup ipv4.google.com
> Server: 2001:4:1f:98::2
> Address:2001:4:1f:98::2#53
> 
> Non-authoritative answer:
> ipv4.google.com canonical name = ipv4.l.google.com.
> Name:   ipv4.l.google.com
> Address: 216.58.218.110
> 
> Shouldn't the address (last line) be an IPv6 address (prefixed IPv4 address, 
> created by NAT64, such as 64:ff9b::216.58.218.110)?

Nope.  Whether your local system connects to IPv4 addresses via NAT64-formatted 
IPv6 addresses is unrelated to DNS lookups of A or  records.  If you ask 
for an A record, you will get IPv4 address(es) back or 0 records, not an IPv6 
address.

By the way, debugging DNS issues by using nslookup is difficult; try switching 
to dig and consider the results of running "dig -t a ipv4.l.google.com." and 
"dig -t  ipv4.l.google.com."

Regards,
-- 
-Chuck

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

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

Re: global server load balancing with the domain name

[Chuck Swiger]

On Apr 14, 2017, at 2:40 PM, McDonald, Daniel (Dan) 
 wrote:
> Setting up global server load balancing seems easy enough – just add ns 
> records pointing at the load balancer and away you go:
>  
> example.com. 38400INSOAns20.example.net. 
> dan\.mcdonald.example.com. 2017011107 10800 3600 604800 3600
> example.com. 38400INNS   ns1.example.com.
> example.com. 38400INNS   ns2.example.com.
> test.example.com. 900 INNS   
> gslb1.example.com.
> test.example.com. 900 INNS   
> gslb2.example.com.

Are your load-balancers providing different DNS replies to different clients?

Most organizations don't need to place the nameservers themselves behind a LB.

> That works fine for test.example.com.  But when I go to production, I need to 
> do it for example.com and www.example.com.  How do I delegate just the A 
> record and not the SOA, TXT, MX, SPF, and NS records, nor any of the other 
> entries in the zone.  As I recall, I can’t just delegate , as an example,  
> www.example.com, then use a CNAME for example.com.

You can't delegate individual records-- you delegate zones.

If you had multiple DCs available, you might use a CNAME to point 
www.example.com to www.dc1.example.com, www.dc2.example.com, etc based upon 
whatever criteria seems reasonable, such as availability, client geolocation 
data, etc.  For web traffic, it is common to set a session cookie or similar 
for session affinity to keep requests going to the same DC once a given client 
has landed there.

You might want to have a chat with someone from Akamai, Level3, or one of the 
other CDN players.

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

[Chuck Swiger]

On Jan 4, 2017, at 4:11 PM, Debarghya Mandal  wrote:
> Hi,
> I am kind of new to bind. I have a few queries about it.
> 
> 1. Is there a way to load custom DNS record from zone file?

Yes; that's exactly what zone files are for.

> I have some schematized data that I can store say in json or xml format. I 
> want bind to load that custom record.

If you have the data in a structured format, simply process that into the zone 
file format used by BIND.  Or, you might consider alternatives like PowerDNS 
which provides more explicit support for backends like databases, LDAP, json, 
and so forth.

> 2. Once bind loads that data, for certain zones, for A//CNAME request 
> types I want bind to call my custom code which knows how to process that 
> custom record and return a valid A//CNAME record.
> DynDB extension is the best way to add a plugin to bind or there is some 
> other alternative?

Start with dynamic zones and update the specific records via nsupdate.  Use 
views to provide different answers to different classes of requestors if 
absolutely needed.

You should remember that DNS requests tend to be extensively cacheable, so 
trying to provide different answers to the same query isn't going to work 
unless you use very short TTLs, and even then clients may still enforce a 
minimum TTL of 5 minutes or so.

(Even BIND itself had a min_cache_ttl set to a default of 300 seconds, way back 
when.)

Regards,
-- 
-Chuck

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

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

Re: reverse resolution failing

[Chuck Swiger]

Hi--

On Apr 10, 2013, at 1:07 PM, Jim Pazarena wrote:
 So I have another domain which will not reverse resolve for me:
 
 mail.tysers.com which also appears to be:
 mail.tyser.co.uk
 
 80.169.188.226
 
 the IP, will not reverse resolve (for me) yet, once again,
 google (8.8.8.8) CAN RESOLVE IT.
 
 On my original post, Tony Finch advised the nameservers for
 the target are very broken.
 
 But why is it that google can STILL resolve it?
 Do they have some special setting which pushes thru poorly
 configured DNS?

Nope, colt.net simply has only one out of three listed nameservers
working well enough to return an answer rather than NXDOMAIN:

% dig -x 80.169.188.226 @ns2.colt.net
[ ... ]
;; -HEADER- opcode: QUERY, status: NOERROR, id: 26181
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 0

;; QUESTION SECTION:
;226.188.169.80.in-addr.arpa.   IN  PTR

;; ANSWER SECTION:
226.188.169.80.in-addr.arpa. 86400 IN   PTR mail.tysers.com.
226.188.169.80.in-addr.arpa. 86400 IN   PTR mail.tyser.co.uk.

;; AUTHORITY SECTION:
169.80.in-addr.arpa.86400   IN  NS  ns4.colt.net.
169.80.in-addr.arpa.86400   IN  NS  ns2.colt.net.
169.80.in-addr.arpa.86400   IN  NS  ns3.colt.net.

% dig -x 80.169.188.226 @ns3.colt.net
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 21747
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;226.188.169.80.in-addr.arpa.   IN  PTR

;; AUTHORITY SECTION:
169.80.in-addr.arpa.86400   IN  SOA ns2.colt.net. 
eudnsmaster.colt.net. 2013044938 10800 3600 604800 86400

% dig -x 80.169.188.226 @ns4.colt.net
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 2133
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;226.188.169.80.in-addr.arpa.   IN  PTR

;; AUTHORITY SECTION:
169.80.in-addr.arpa.86400   IN  SOA ns2.colt.net. 
eudnsmaster.colt.net. 2013044938 10800 3600 604800 86400

 Is there anything I can do to MY named to get this working?

Yes and no.  You could claim to be authoritative for the reverse zone,
but that won't fix it for anyone else.  Get colt.net to fix their broken DNS 
servers.

Regards,
-- 
-Chuck

___
Please visit https://lists.isc.org/mailman/listinfo/bind-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 minimize the downtime in my case

[Chuck Swiger]

Hi--

On Mar 14, 2013, at 12:04 PM, Manish Rane wrote:
 I right now have NS server hosted with ISP and I am planning to set up my own 
 BIND servers. Now I would like to understand that I need to ask my Registrar 
 to populate the entry of my new NS server which would take 4-6 hours to 
 propagate over the internet.
 
 To reduce the downtime, can I not add those two new NS servers along with my 
 old DNS server with exact zone? once all the NS entries populate over the 
 internet I can have my ISP's DNS removed and have one of my DNS server as 
 Master?

You can.

 once all the NS entries populate over the internet I can have my ISP's DNS 
 removed and have one of my DNS server as Master?

Sure.  Validate that your new servers work before turning off the old ones for 
the zone with your registrar, but otherwise, you should be fine.

Regards,
-- 
-Chuck

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

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

Re: cname record

[Chuck Swiger]

Hi, Dwayne--

On Mar 1, 2013, at 10:29 AM, Dwayne Hottinger wrote:
 I would like for users inside my network to not be able to do ssl searches 
 with google, because of cipa compliance issues.

OK, so you should block port tcp/443 to Google's network addresses 
(approximately 173.194.79.0/24) on your firewall.

  I added a cname record to my zone file:
 
 www.google.com CNAME nosslsearch.google.com
 
 To try and get it to redirect.  Since Im not authoritive for google, I dont 
 think this will work no matter how I tweak it.  Am I right in this assumption?

You can use RPZ capabilities in BIND to override their records:

  http://www.isc.org/software/rpz

...but that won't do anything to prevent a knowledgeable user from hitting 
something like https://173.194.79.99/ directly.

Regards,
-- 
-Chuck

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

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

Re: broken ISP in china

[Chuck Swiger]

Hi--

On Feb 18, 2013, at 2:07 PM, Lyle Giese wrote:
 Recently I moved this domain(lcrcomputer.net) to a registrar that suports 
 DNSSEC and inserted the DS record for this domain.  I checked DNSSEC via  
 http://dnsviz.net and http://dnssec-debugger.verisignlabs.com.  Both show 
 DNSSEC is working just fine for lcrcomputer.net.
 
 However, shortly after that one of my customers stopped receiving email from 
 one of their clients in China.  They just brought that to my attention and I 
 tried to email the client in China and got this back:
 
 For ro...@x.com.cn, Site (x.com.cn/ipv4 address) said: 559 sorry 
 , your helo/ehlo and domain in mail are invalid, you don't connect from 
 there. (#5.5.9)

You've removed too much of the error logging and context to reliably debug the 
issue.
Perhaps try asking postmas...@.com.cn to confirm that they are seeing 
current DNS records for your domain.

 Because this started within 24 hours of when I published the DS record for 
 lcrcomputer.net, I am assuming that this is related.
 
 Had anyone else run across this?  Or do I have something misconfigured here?


Well, the nameserver at ns1.lcrcomputer.net aka 209.112.71.50 doesn't seem to 
be responding:

$ dig www.lcrcomputer.com @ns1.lcrcomputer.net
;  DiG 9.6-ESV-R4-P3  www.lcrcomputer.com @ns1.lcrcomputer.net
;; global options: +cmd
;; connection timed out; no servers could be reached

That's not helping matters, but it shouldn't be fatal since the other two 
nameservers do seem to be responding.

Regards,
-- 
-Chuck

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

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

Re: MNAME not a listed NS record

[Chuck Swiger]

On Jan 16, 2013, at 12:40 PM, Dave Warren wrote:
 Is there anything technically wrong with having a SOA MNAME field that isn't 
 listed as a NS record?

Sure.  The SOA MNAME is expected to be the primary master nameserver for the 
zone; it's where things like dhcpd and such send dynamic updates for the zone 
to.

 The server listed as MNAME will host the zone and is authoritative for the 
 zone, but out of latency concerns it isn't ideal to have other resolvers 
 querying this server.

Okay...so why would you use that nameserver at all, then?

Choose a nameserver which is suitable for other resolvers to query for your 
master.

 Various online DNS diagnostic tools throw warnings, but as far as I can tell 
 from the RFCs, this is a valid configuration. Is it valid? Are there any 
 operational gotchas to be aware of or can I ignore the warnings?

It's not valid, but if you aren't doing dynamic updates to the zone, and you 
can live without SOA serial # sanity checking by slave nameservers trying to 
determine whether the zone has been updated or not by checking with the MNAME 
server, sure, you can setup DNS in such a fashion and (probably) nothing else 
would break.

Regards,
-- 
-Chuck

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

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

Re: MNAME not a listed NS record

[Chuck Swiger]

On Jan 16, 2013, at 1:42 PM, Barry Margolin wrote:
 In article mailman.1077.1358370123.11945.bind-us...@lists.isc.org,
 Chuck Swiger cswi...@mac.com wrote:
 
 On Jan 16, 2013, at 12:40 PM, Dave Warren wrote:
 Is there anything technically wrong with having a SOA MNAME field that 
 isn't listed as a NS record?
 
 Sure.  The SOA MNAME is expected to be the primary master nameserver for 
 the zone; it's where things like dhcpd and such send dynamic updates for the 
 zone to.
 
 But that doesn't mean it should be the server for resolver queries.

True, but I don't see much utility from a nameserver which can be dynamically
updated but not queried.

 The server listed as MNAME will host the zone and is authoritative for the 
 zone, but out of latency concerns it isn't ideal to have other resolvers 
 querying this server.
 
 Okay...so why would you use that nameserver at all, then?
 
 Choose a nameserver which is suitable for other resolvers to query for your 
 master.
 
 The master could be behind a firewall that only allows the published 
 nameservers to connect to it.

Sure.  In which case, why publish an internal-only machine into the public
DNS via your SOA record?  Someone else made mention of a stealth master,
but my definition of that is an internal machine which is not visible in
any publicly published records.

 The performance requirements of a nameserver that serves public queries 
 are different from a server that only has to respond to zone transfer 
 requests from the published nameservers.

True.  Handling AFXRs isn't much work, and you can always revert to other 
methods
of replicating zone data if need be, so my primary concern is making nameservers
work well enough to handle the query load, and not to make nameservers just 
handle
zone transfers.

Regards,
-- 
-Chuck

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

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

Re: MNAME not a listed NS record

[Chuck Swiger]

On Jan 16, 2013, at 4:30 PM, Barry Margolin wrote:
[ ... ]
 On Jan 16, 2013, at 12:40 PM, Dave Warren wrote:
 Is there anything technically wrong with having a SOA MNAME field that 
 isn't listed as a NS record?
 
 Sure.  The SOA MNAME is expected to be the primary master nameserver for 
 the zone; it's where things like dhcpd and such send dynamic updates for 
 the zone to.
 
 But that doesn't mean it should be the server for resolver queries.
 
 True, but I don't see much utility from a nameserver which can be dynamically
 updated but not queried.
 
 Who says you're using dynamic update? The MNAME field has been part of 
 the DNS standard since long before DHCP and dynamic update.  In many 
 instances it's just an FYI field.

Nothing says one is using dynamic updates; if you aren't, then sure, the
MNAME field is quite a bit less important than if you are.

[ ... ]
 Sure.  In which case, why publish an internal-only machine into the public
 DNS via your SOA record?  Someone else made mention of a stealth master,
 but my definition of that is an internal machine which is not visible in
 any publicly published records.
 
 You have to put something in the MNAME. You could lie and put one of the 
 public nameservers, but why do that when you could put the true master?

Are you asking why someone would not publish an internal-only hostname?

Maybe it's using RFC-1918 addresses and only reachable on one's LAN?

 The performance requirements of a nameserver that serves public queries 
 are different from a server that only has to respond to zone transfer 
 requests from the published nameservers.
 
 True.  Handling AFXRs isn't much work, and you can always revert to other 
 methods of replicating zone data if need be, so my primary concern is making 
 nameservers work well enough to handle the query load, and not to make 
 nameservers
 just handle zone transfers.
 
 Do that on the public nameservers.  The hidden master doesn't need to be 
 dedicated to nameserving, since it's not handling all the load that the 
 public servers do.

Sure.  The thing is, by the time an organization grows big enough to maintain
dedicated internal and external DNS views, and loads their DNS servers to the
point where dedicating a server just to act as master for zone data rather than
handling queries makes sense, well, you also tend to end up with firewalls,
load-balancers, and such which can redirect traffic based on source address,
server load and aliveness, etc.

You publish VIPs which handle your DNS traffic, and then balance that internally
onto your pool of reals (the DNS server boxes) as you choose.  Keeping query 
load
low or moving it entirely off of a particular box is a LB config change.  
YMMV

Regards,
-- 
-Chuck

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

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

Re: Find all authoritative domains for a nameserver?

[Chuck Swiger]

Hi--

On Dec 3, 2012, at 3:30 PM, Novosielski, Ryan wrote:
 I don't know if there's an easy, or even moderately easy way to do
 this, but can one somehow figure out/get a list of all domains for
 which the nameserver is set to a given IP/server name?

It's easy enough to test whether a specific domain is being delegated
to your nameserver by checking WHOIS or asking for NS records for the domain.
It's also easy enough if you have access to the nameserver configs to
see which domains it is setup to be authoritative for.

However, since someone could delegate some.strange.subdomain.from.my.domain
to an arbitrary nameserver (ie, yours), there's no way of exhaustively
identifying these even if you check WHOIS or the root nameservers AFAIK

 For reasons I won't get into, the people who register the domains are not the 
 same
 as the people who run the DNS servers (me) and occasionally the
 domains I have zones defined for in my nameservers do not match the
 WHOIS records. Normally, that problem becomes pretty obvious because
 nothing works right, but it does generate a lot of logging for failed
 queries to the nameservers. I guess that would be one way to tell when
 someone has made us authoritative for a domain but not had us create a
 zone file, but is there a way to get a list somehow?

Registrars are expected to have both a billing/admin contact and a
technical contact; make sure that people who expect you to make their
domains work put you as the tech contact, and you will at least get
notified when they register new top-level domains.

Regards,
-- 
-Chuck

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

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

Re:

[Chuck Swiger]

Hi--

On Nov 29, 2012, at 3:00 PM, Jose Manuel Delgado G. wrote:
 I have the following problem in resolving my DNS using Bind 9, sends me an 
 error connection time out, no servers Could be reached. that way I can avoid 
 giving these errors and how I can reduce the time of the response?
 
 this example with my server and public google dns server.
 
 # dig @8.8.8.8 videolinedvd.com
[ ... ]

You've got two nameservers for the domain per WHOIS as:

   Domain servers in listed order:
  NS1.VIDEOLINEDVD.COM
  NS2.VIDEOLINEDVD.COM

...but they don't have A records setup.  Your nameservers must have A records:

% dig NS1.VIDEOLINEDVD.COM @8.8.8.8
[ ... ]
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 36700
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;NS1.VIDEOLINEDVD.COM.  IN  A

See http://www.dnsvalidation.com/reports/50b7e96a7d79ee480a04

Regards,
-- 
-Chuck

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

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

Re:

[Chuck Swiger]

On Nov 29, 2012, at 3:34 PM, Jose Manuel Delgado G. wrote:
 about the other question, as to reduce the response time of my server when 
 the domain does not exist?

BIND implements negative caching of NXDOMAIN responses:

% dig www.does.not.exist. @localhost
[ ... ]
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 4942
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.does.not.exist.IN  A

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

;; Query time: 360 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Nov 29 18:35:52 2012
;; MSG SIZE  rcvd: 111

% dig www.does.not.exist. @localhost
[ ... ]
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 55697
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.does.not.exist.IN  A

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

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Nov 29 18:36:03 2012
;; MSG SIZE  rcvd: 111

Regards,
-- 
-Chuck

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

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

Re: Performance tuning

[Chuck Swiger]

Hi--

On Nov 26, 2012, at 10:12 AM, Adamiec, Lawrence wrote:
 The report must also address these two specific questions:
 
   • Why does www.kentlaw.iit.edu load quicker than kentlaw.iit.edu in any 
 browser?
   • What happens if we remove the forwarders option from named.conf?
 I can't duplicate the issue in Q1 and I'm trying to determine a way of 
 testing Q2.

Q1 isn't related to DNS performance; both of the names you mention resolve to 
the same IP address via an A record.  There wasn't a significant difference in 
response time I saw by loading the webpages (both took ~1.3 s per curl), but 
one likely could improve webserver performance by running Apache, nginx, or 
almost anything else instead of than Microsoft's IIS.

The domain seems to be missing A records for your nameservers, however:

  http://www.dnsvalidation.com/reports/50b3b5167d79ee02b826

As for Q2, it depends on whether the nameservers you are pointing to do better 
in caching queries then your local nameservers would doing recursive lookups 
for themselves.  If the local nameservers have poor connectivity compared to 
the forwarders, maybe, otherwise it's probably not helpful to use forwarders.

Regards,
-- 
-Chuck

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

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

Re: transparent DNS load-balancing with a Cisco ACE

[Chuck Swiger]

Hi--

On Oct 19, 2012, at 11:25 AM, John Miller wrote:
 Hello everyone,
 
 Perhaps a Cisco list is a better destination for this, but I've seen a 
 similar post here in the past couple of months, so posting here as well.
 
 I'm trying to get our Cisco ACE set up appropriately to handle DNS traffic.  
 So far, I've gotten it working using NAT (each rserver has a public and a 
 private IP) and using transparent load-balancing (ACE talks directly to the 
 public IP), aka direct server return.

IMO, the only boxes which should have IPs in both public and private netblocks 
should be your firewall/NAT routing boxes.

 Here's a question, however: how does one get probes working for a transparent 
 LB setup?  If an rserver listens for connections on all interfaces, then 
 probes work fine, but return traffic from the uses the machine's default IP 
 (not the VIP that was originally queried) for the source address of the 
 return traffic.

That's the default routing behavior for most platforms.  Some of them might 
support some form of policy-based routing via ipfw fwd / route-to or similar 
with other firewall mechanisms which would let the probes get returned from 
some other source address if you want them to do so.

 What have people done to get probes working with transparent LB?  Are any of 
 you using NAT to handle your dns traffic?  Not tying up NAT tables seems like 
 the way to go, but lack of probes is a deal-breaker on this end.

The locals around here have the luxury of a /8 netblock, so they can setup the 
reals behind a LB using publicly routable IPs and never need to NAT upon DNS 
traffic.  Folks with more limited # of routable IPs might well use LB to reals 
on an unrouteable private network range behind NAT, but in which case they 
wouldn't configure those boxes with public IPs.

Regards,
-- 
-Chuck

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

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

Re: transparent DNS load-balancing with a Cisco ACE

[Chuck Swiger]

Hi--

On Oct 19, 2012, at 1:04 PM, John Miller wrote:
 IMO, the only boxes which should have IPs in both public and private 
 netblocks should be your firewall/NAT routing boxes.
 
 That's how we usually have our servers set up--the load balancer gets the 
 public IPs, the servers get the private IPs, and we use NAT to translate 
 between the two.

OK.

 Here's a question, however: how does one get probes working for a 
 transparent LB setup?  If an rserver listens for connections on all 
 interfaces, then probes work fine, but return traffic from the uses the 
 machine's default IP (not the VIP that was originally queried) for the 
 source address of the return traffic.
 
 That's the default routing behavior for most platforms.  Some of them might 
 support some form of policy-based routing via ipfw fwd / route-to or similar 
 with other firewall mechanisms which would let the probes get returned from 
 some other source address if you want them to do so.
 
 Good to know--you'd definitely expect traffic to come back on the main 
 interface.  I've considered setting up some iptables rules to make this 
 happen, but if I can avoid it, so much the better.  Sounds like this is what 
 I need to do, however, if I want both probes and regular requests to work.

Perhaps I misunderstand, but if the internal boxes only have one IP, how can 
they not be using the right source address when replying to liveness probes 
from your LB or some other monitor?  Do you probe on an external IP and have 
something else doing NAT besides the LB itself?

Or do you setup a second IP on your reals which is what the LB sends traffic to?
(That's kinda what your lo:1 entry of 129.64.x.53 looked like.)

 What have people done to get probes working with transparent LB?  Are any 
 of you using NAT to handle your dns traffic?  Not tying up NAT tables seems 
 like the way to go, but lack of probes is a deal-breaker on this end.
 
 The locals around here have the luxury of a /8 netblock, so they can setup 
 the reals behind a LB using publicly routable IPs and never need to NAT upon 
 DNS traffic.  Folks with more limited # of routable IPs might well use LB to 
 reals on an unrouteable private network range behind NAT, but in which case 
 they wouldn't configure those boxes with public IPs.
 
 We're on a /16, so we have plenty of public IPs (though not as many as you!) 
 to play with, too.  The choice to NAT has historically been more about 
 security than anything else--if something is privately IPed, we've got it on 
 a special VLAN as well.

OK.  I've seen too many examples of traffic leaking between VLANs to completely 
trust their isolation, but good security ought to involve many layers which 
don't have to each be perfect to still provide worthwhile benefits.

 Presumably those reals are still behind a virtual ip address that's also 
 public, right?

Yes, presumably.  :)

 If that's the case, how do you keep your probes (to the IP behind the LB) 
 working, while still sending back regular DNS traffic (that was originally 
 sent to the virtual IP) with the VIP as a source address?  Seems like you get 
 only one or the other unless you tweak iptables/ipfw/etc.

There are two types of probes that I'm familiar with.

One involves liveness probes between the LB itself to the reals, which is done 
so that the LB can decide which of the reals are available and should be 
getting traffic.  For these, the reals are replying using their own IPs.  The 
other type of probe is to the VIP; the LB forwards traffic to the reals, gets a 
reply, and then proxies or rewrites these responses and returns them to the 
origin of the probe using the IP of the VIP.  Or you can short-cut replies 
going back via the LB using DSR (Direct Service Return), or whatever your LB 
vendor calls that functionality...

All of your normal clients would only be talking to the VIP, and would only see 
traffic coming from the VIP's IP.

 I appreciate the help, Chuck!  Would you mind PMing me or posting your 
 configs?  That might be the most useful.

Pretend that some folks nearby are using Citrix Netscaler MPX boxes rather than 
Cisco hardware, so this might not be too useful to your case; an example config 
for a webserver would look something like:

add serviceGroup SomeService-svg HTTP -maxClient 0 -maxReq 0 -cip ENABLED 
x-user-addr -usip NO -useproxyport YES -cltTimeout 120 -svrTimeout 300 -CKA YES 
-TCPB YES -CMP NO
add lb vserver LB-SomeService-80 HTTP 1.2.3.4 80 -persistenceType NONE 
-cltTimeout 120
bind lb vserver LB-SomeService-80 SomeService-svg
bind serviceGroup SomeService-svg rserver1 8080
bind serviceGroup SomeService-svg rserver2 8080
bind serviceGroup SomeService-svg rserver3 8080
bind serviceGroup SomeService-svg rserver4 8080

[ This is a generic example for a webserver, or for similar things which use 
HTTP to communicate.  Another group handles DNS, so I don't have a generic 
example for that handy.  And yeah, NDA issues prevent me from being as 

Re: Possible DDoS?

[Chuck Swiger]

Hi--

On Oct 17, 2012, at 11:17 AM, Manson, John wrote:
 From time to time I notice a large number of queries like these to one of my 
 external dns servers:
  
 14:14:40.01407 121.10.105.66 - 143.231.1.67 DNS C gop.gov. Internet * ?
 [ ... ]
 14:14:40.98668 121.10.105.66 - 143.231.1.67 DNS C gop.gov. Internet * ?
 14:14:40.99417 121.10.105.66 - 143.231.1.67 DNS C speaker.gov. Internet * ?
  
 Does this rise to the level of a DDoS attack?
 No NS record for this IP.
 I blackhole IPs that behave like this.

That sure looks to be a DNS-based DDoS.  Note that IP 121.10.105.66 is actually
the victim being attacked-- the attackers forge that address and make queries 
which
send lots of traffic to it.

Blackholing them on your side will mitigate against the DDoS, but also break any
legitimate traffic which they might send.  (They can always use public DNS 
servers
like 4.2.2.1 or 8.8.8.8 if they need to, though, so don't worry about legit
requests from them too much.)

Regards,
-- 
-Chuck

___
Please visit https://lists.isc.org/mailman/listinfo/bind-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 BIND Failover Setup (High Availability)

[Chuck Swiger]

On Sep 14, 2012, at 4:37 AM, Kaushal Shriyan wrote:
 Can someone please point me to setup High Availability BIND DNS Server
 on CentOS Linux version 5.8?

Sure; read the fine BIND ARM:

   http://www.isc.org/software/bind/documentation

Setup and register as many nameservers for your domains as you find useful
considering # of datacenters available, per-DC replication, etc to meet your HA 
goals.

Regards,
-- 
-Chuck

___
Please visit https://lists.isc.org/mailman/listinfo/bind-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 BIND Failover Setup (High Availability)

[Chuck Swiger]

On Sep 14, 2012, at 4:36 PM, Kaushal Shriyan wrote:
 Thanks for the reply. Basically i am setting up Internal DNS Server
 within the same DC. Will Master Slave Replication suit the need?

Yes.  (Oh, there are other ways of doing replication, but AFXR works fine.)

 and any step by step guide and what all security aspects need to be taken 
 care.

Why don't you read the fine docs and let us know if you run into a specific 
problem?

Regards,
-- 
-Chuck

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

[Chuck Swiger]

On Jul 12, 2012, at 2:27 AM, Dns Administrator wrote:
 Hi  bind-users,
please excuse my ignorance being a novice to dns, but is there some way of 
 disabling or choking Any type requests?

Sure-- a firewall or even taking a pair of wire-cutters to the ethernet cable 
will accomplish that.  :-)

Regards,
-- 
-Chuck

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

[Chuck Swiger]

On Jul 12, 2012, at 7:16 AM, Lightner, Jeff wrote:
 Your answer was clearly meant to be tongue in cheek but I'm not sure you 
 understood.

Please allow me to reassure you that I understood the intent of the question.  
:-)

The point was that if one isn't clear about what one should allow and what one 
should forbid, spending lots of money on a fancy firewall box, or complicated 
rules creating restrictions for certain DNS query types is silly-- a pair of 
wirecutters provides better security for your money:

  http://www.ranum.com/security/computer_security/papers/a1-firewall/
  http://www.google.com/search?q=firewall+wizards+wirecutters

 The OP wasn't asking how to stop all (any) lookups - it was how to stop dig 
 -t any which isn't the same thing at all.  Presumably they still want to 
 allow dig -t mx, dig www... etc...
 
 Personally I don't know why dig -t any would be a problem.   It's not 
 exactly the same as doing an axfr transfer of the zone - it still only gets 
 limited information.

That's an extremely good question to ask, yes.

However, it should also lead to asking why would you want to answer DNS 
queries at all for some client, if you've decided you want to block some types 
of queries?  If whoever it is making the DNS requests is a valid user of the 
nameserver, then you probably ought to figure out what's going on by talking 
with them before simply breaking things.  If the queries aren't from a valid 
user, consider not answering any of queries, rather than just blocking some.

If the intent is to mitigate a DDOS/amplification attack but still allow public 
access to the nameserver, well, rate limiting queries seems to be a much more 
appropriate solution than blocking type=any.

Regards,
-- 
-Chuck

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

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

Re: CNAME Rules

[Chuck Swiger]

On Jun 25, 2012, at 2:13 PM, Srinivas Krishnan wrote:
 The RFC rules on CNAMEs is fairly tight but I am seeing an increasing
 amount of traffic with misconfigured CNAMEs some of which are accepted
 by BIND as valid responses. The examples capture three trends, note
 these are actual responses:
 
 1) Example-1: CNAME in the additional section necessary to finish
 processing of response. BIND accepts this as valid:
 
 proto: DNS: id=febd qr=1 QUERY AA NOERROR qdcount=1 ancount=7
 nscount=6 arcount=7
query: after12.failblog.org. A IN
answer: after12.failblog.org. CNAME IN TTL=3600 
 chzallnighter.wordpress.com.
answer: vip-lb.wordpress.com. A IN TTL=300 72.233.104.123
nameserver: wordpress.com. NS IN TTL=14400 ns1.wordpress.com.
nameserver: wordpress.com. NS IN TTL=14400 ns2.wordpress.com.
additional: chzallnighter.wordpress.com. CNAME IN TTL=300
 vip-lb.wordpress.com.
additional: ns1.wordpress.com. A IN TTL=14400 72.233.69.14
additional: ns2.wordpress.com. A IN TTL=14400 76.74.159.137

This is standard CNAME chaining, per RFC-1034:

% dig after12.failblog.org @8.8.8.8
[ ... ]
;; QUESTION SECTION:
;after12.failblog.org.  IN  A

;; ANSWER SECTION:
after12.failblog.org.   3416IN  CNAME   chzallnighter.wordpress.com.
chzallnighter.wordpress.com. 116 IN CNAME   vip-lb.wordpress.com.
vip-lb.wordpress.com.   116 IN  A   74.200.247.187
vip-lb.wordpress.com.   116 IN  A   76.74.255.117
vip-lb.wordpress.com.   116 IN  A   76.74.255.123
vip-lb.wordpress.com.   116 IN  A   72.233.104.123
vip-lb.wordpress.com.   116 IN  A   72.233.127.217
vip-lb.wordpress.com.   116 IN  A   74.200.247.59

 2) Example-2: Multiple CNAMEs with same label but different data, BIND
 finds this to be incorrect and retries if another nameserver is
 available:
 
 
 proto: DNS: id=8faa qr=1 QUERY AA NOERROR qdcount=1 ancount=2 nscount=13
query: image.dhgate.com. A IN
answer: image.dhgate.com. CNAME IN TTL=7200 image.dhgate.chinacache.net.
answer: image.dhgate.com. CNAME IN TTL=7200 image.dhgate.com.cdn20.com.
nameserver: . NS IN TTL=518400 a.root-servers.net.
nameserver: . NS IN TTL=518400 b.root-servers.net.
nameserver: . NS IN TTL=518400 c.root-servers.net.

% dig image.dhgate.com @8.8.8.8
[ ... ]
;; QUESTION SECTION:
;image.dhgate.com.  IN  A

;; ANSWER SECTION:
image.dhgate.com.   26  IN  CNAME   image.dhgate.com.cdn20.com.
image.dhgate.com.cdn20.com. 29  IN  CNAME   image.dhgate.com.wscdns.com.
image.dhgate.com.wscdns.com. 29 IN  CNAME   dhgate.com.edgesuite.net.
dhgate.com.edgesuite.net. 1381  IN  CNAME   a1015.b.akamai.net.
a1015.b.akamai.net. 20  IN  A   65.121.208.137
a1015.b.akamai.net. 20  IN  A   65.121.208.120

I wonder where chinacache.net came from in your case, unless they are using
different CDNs in different parts of the world.  Around here, they're using
Akamai EdgeSuite.

Again, this looks to be standard CNAME chaining, only your query didn't chase
image.dhgate.com.cdn20.com any further.

 3) Example-3: Multiple CNAMEs with same and data, BIND finds this to
 be incorrect as well and retries.
 
 proto: DNS: id=a0f6 qr=1 QUERY AA NOERROR qdcount=1 ancount=2
 nscount=3 arcount=3
query: www.smilebox.com. A IN
answer: www.smilebox.com. CNAME IN TTL=3600 www.g.smilebox.com.
answer: www.smilebox.com. CNAME IN TTL=3600 www.g.smilebox.com.
nameserver: smilebox.com. NS IN TTL=86400 ns1.smilebox.com.
nameserver: smilebox.com. NS IN TTL=86400 ns2.smilebox.com.
nameserver: smilebox.com. NS IN TTL=86400 ns3.smilebox.com.
additional: ns1.smilebox.com. A IN TTL=86400 207.66.132.8
additional: ns2.smilebox.com. A IN TTL=86400 216.218.214.52
additional: ns3.smilebox.com. A IN TTL=86400 71.164.20.101
 
 My question really what are the rules governing CNAME processing in
 BIND and why does Example-1 allowed as valid.

From here, this gets:

% dig www.smilebox.com @8.8.8.8
[ ... ]
;; QUESTION SECTION:
;www.smilebox.com.  IN  A

;; ANSWER SECTION:
www.smilebox.com.   3421IN  CNAME   www.g.smilebox.com.
www.g.smilebox.com. 121 IN  A   216.218.214.53

...which is a single CNAME pointing to an A record.  Are you sure your 
ancount=2
was really two copies of the same CNAME, rather than a CNAME and A record?

Regards,
-- 
-Chuck

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

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

Re: CNAME Rules

[Chuck Swiger]

On Jun 25, 2012, at 2:34 PM, Srinivas Krishnan wrote:
 You are using a caching resolver to check the responses and you only see 
 response after its been resolved by Google's DNS server.

The overwhelming majority of Internet users are using caching resolvers running 
at their ISP, employer, etc.  :-)

 Try dig @ns1.wordpress.comafter12.failblog.org. to see the actual records 
 that you would receive if you were a DNS server performing an authoritative 
 query to wordpress.
 
 Is having a CNAME in the additional section regular CNAME chaining, my 
 understanding was that additional sections do not contain CNAMEs. 

The wordpress nameserver is hoping to short-circuit a series of requests 
following the CNAME chain by including the data in the additional section:

% dig after12.failblog.org. @ns1.wordpress.com
[ ... ]
;; -HEADER- opcode: QUERY, status: NOERROR, id: 27255
;; flags: qr aa rd; QUERY: 1, ANSWER: 7, AUTHORITY: 6, ADDITIONAL: 7
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;after12.failblog.org.  IN  A

;; ANSWER SECTION:
after12.failblog.org.   3600IN  CNAME   chzallnighter.wordpress.com.
vip-lb.wordpress.com.   300 IN  A   74.200.247.187
vip-lb.wordpress.com.   300 IN  A   74.200.247.59
vip-lb.wordpress.com.   300 IN  A   76.74.255.117
vip-lb.wordpress.com.   300 IN  A   72.233.104.123
vip-lb.wordpress.com.   300 IN  A   72.233.127.217
vip-lb.wordpress.com.   300 IN  A   76.74.255.123

;; AUTHORITY SECTION:
wordpress.com.  14400   IN  NS  ns1.wordpress.com.
wordpress.com.  14400   IN  NS  ns2.wordpress.com.
wordpress.com.  14400   IN  NS  ns3.wordpress.com.
wordpress.com.  14400   IN  NS  ns4.wordpress.com.
wordpress.com.  14400   IN  NS  ns5.wordpress.com.
wordpress.com.  14400   IN  NS  ns6.wordpress.com.

;; ADDITIONAL SECTION:
chzallnighter.wordpress.com. 300 IN CNAME   vip-lb.wordpress.com.
ns1.wordpress.com.  14400   IN  A   72.233.69.14
ns2.wordpress.com.  14400   IN  A   76.74.159.137
ns3.wordpress.com.  14400   IN  A   64.34.177.159
ns4.wordpress.com.  14400   IN  A   72.233.104.98
ns5.wordpress.com.  14400   IN  A   69.174.248.140
ns6.wordpress.com.  14400   IN  A   64.34.174.135

A paranoid nameserver would discard the A records in the ANSWER section and the 
CNAME for ADDITIONAL SECTION as not matching the query, but then it would have 
to follow the CNAME and look those records up anyway...

Regards,
-- 
-Chuck

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

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

Re: OT: cached memory

[Chuck Swiger]

On Jun 13, 2012, at 3:02 PM, Dan Letkeman wrote:
 I understand the concept, as I have read many documents like that.  I
 am more interested in a real world example of how much free memory for
 caching is recommended for an average server.

The OS likes to keep a few megabytes of prezeroed pages handy for
emergency purposes, but otherwise, free memory is wasted memory.

One can infer that more memory would help system performance if
you are using more than a minor amount of swap, or if you see
significant amounts of paging/swapping in vmstat or similar...

Regards,
-- 
-Chuck

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

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

Re: Problem with recursive name server

[Chuck Swiger]

Hi--

On Jun 8, 2012, at 1:08 PM, Mike Bobkiewicz wrote:
 we are running an authorative name server for some domains. After some time 
 our ISP has now delegated the reverse name lookups to our server. We are 
 running bind 9.7.3 on Mac OS X 10.6 and are not able to bring the reverse 
 name lookups to life. The master db-file is loaded and we  to set the 
 allow-recursive { any; }; option in the named.conf but it still doesn´t work. 
 We are getting RFC 1912 2.1 with some mail servers which is the biggest 
 problem. Which additional options must be set in the named.conf to make the 
 reverse name lookups for our domains work?

Mailservers doing a double-reverse lookup try to validate that your IP has a 
PTR record which returns a name that a normal forward lookup finds, and gives 
back the original IP.

Give us an example of a bad hostname or IP, and we can probably tell you what 
aspect isn't working right...

Regards,
-- 
-Chuck

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

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

Re: Question

[Chuck Swiger]

On Apr 12, 2012, at 3:38 PM, Dustin Moon wrote:
 Any Reason people could see why this config would not allow remote systems 
 that can ping this server to do lookups on it?

Why, yes-- see the following line:

allow-query { localhost; };

...?

Regards,
-- 
-Chuck

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

[Chuck Swiger]

On Apr 12, 2012, at 3:52 PM, Dustin Moon wrote:
 #allow-query { any; };

Commenting it out entirely is *not* the same thing as changing it to a setting 
which allows remote clients to make queries.

Regards,
-- 
-Chuck

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

[Chuck Swiger]

On Apr 11, 2012, at 10:26 AM, mfla wrote:
 We use 3 BIND each is configured as Master.
 Each domain is configure with 3 NS records according to the above 3 BIND.
 What happens for end users when tthey try to access the domain but one of the 
 BIND server is down ?

Assuming all of the clients were starting with cold caches, one out of three 
requests would go to the down'ed server, and experience a delay of a few 
seconds until the client resolver retries and talks to a working server instead.

After that, most caching nameservers and end-user clients will generally ignore 
the downed server in favor of one that works

Regards,
-- 
-Chuck

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

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

Re: troubleshooting bind

[Chuck Swiger]

Hi--

On Apr 9, 2012, at 9:55 AM, Marseglia, Michael wrote:
[ ... ]
   When configuring BIND for an internal corporate network with a thousand 
 clients should any of the default values be tweaked?  I’ve searched for 
 tuning guidance but I haven’t found any yet.
  
   I’ve taken interest in the tcp-clients, max-ncache-ttl, max-cache-ttl, 
 cleaning-interval and max-cache-size values.  These are all currently set to 
 default.

These are good things to take a look at, yes, although also clients-per-query  
max-clients-per-query.

   I’m guessing in a more volatile network with DHCP and frequent 
 provisioning/deprovisioning of hosts I would want to lower the max-ncache-ttl 
 and max-cache-ttl values.  Is this correct?

That depends-- if the volatile domain is your domain, and BIND is authoritative 
for it, then it will be providing AAs directly from zone data, rather than 
caching responses obtained from some other nameserver.  For the most part, it's 
better for an active domain with frequently changing data to adjust the TTLs 
for the domain to appropriate values, and let named figure things out from 
there...but you can only tweak that for the domains you manage.

   Regarding the tcp-clients option, where can I find the current connection 
 count and how do I know if I’m coming close to this number?  In what type of 
 environment would it be expected to hit the default threshold of 100?

You can see what active TCP sessions are open via something like:

  netstat -p tcp | grep 53

...and add | wc -l if you want to count them.

(You might also want to tweak that a bit to use fgrep .53\  to only match 
port 53...)

I don't think it's expected that many TCP sessions would be needed, since UDP + 
EDNS0 works fine for almost all cases, although as DNSSEC becomes more widely 
adopted it might be the case that more TCP sessions will be used.

   Lastly, if max-cache-size is set to unlimited what happens if BIND consumes 
 all the available memory?  Will the linux kernel terminate the process?  How 
 can I find the value of the current cache size?

Most platforms set up a process datasize limit (commonly set to 1GB or so), 
after which malloc() and friends will fail to get more memory.  The kernel will 
only terminate processes if the entire system runs out of VM, including swap 
space, but the system will generally in an unusable state due to heavy 
paging/swapping before the kernel OOM killer gets invoked.

Regards,
-- 
-Chuck

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

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

Re: Apple OS and DNS resolution (._dns-sd.udp. requests)

[Chuck Swiger]

On 4/5/2012 5:08 AM, Matus UHLAR - fantomas wrote:

Hello,

our customer (an ISP) reported that his clients have problems resolving sites
like facebook, youtube, aplestores and that the problems only affect apple
computers.

I notice many requests for dns service discovery:

Apr 5 09:47:20 t03 named[8324]: security: info: client 195.168.157.82#32844:
query 'cf._dns-sd._udp.132.110.254.10.in-addr.arpa/TXT/IN' denied
Apr 5 09:47:20 t03 named[8324]: security: info: client 195.168.157.82#49019:
query 'cf._dns-sd._udp.132.110.254.10.in-addr.arpa/TXT/IN' denied
Apr 5 09:47:20 t03 named[8324]: security: info: client 195.168.157.82#35647:
query 'cf._dns-sd._udp.132.110.254.10.in-addr.arpa/TXT/IN' denied

these requests are denied, because we use private IPS from those ranges and I
don't want to make them available for users.

Can these requests cause resolving problems on Apple computers?


Those are RFC-2792 service discovery requests, used by Bonjour-- see:

  http://www.dns-sd.org/

Denying them won't affect normal DNS resolution, although setting up 
appropriate answers will help Mac (and Windows) clients find resources like 
printers, proxy servers, and so forth appropriate for the domain they live in.


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

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

DSN for Matus...

[Chuck Swiger]

Hi, Matus--

Your anti-spam measures block direct delivery.  ab...@codefab.com works fine 
(it goes to me, as does postmaster@); I don't know why you would try to do an 
RFC-ignorant lookup on the hostname in the PTR record


Regards,
--
-Chuck


 begin forwarded message 

This is the mail system at host newmail.codefab.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

uh...@fantomas.sk: host fantomas.fantomas.sk[195.168.3.66] said: 550 5.7.1
uh...@fantomas.sk... Your domain does not have a working abuse address.
This violates RFC 2142 - see

http://www.rfc-ignorant.org/tools/lookup.php?domain=rrcs-24-103-228-244.nyc.biz.rr.com
(in reply to RCPT TO command)

--9AC7412265B70.1333640956/newmail.codefab.com
Content-Description: Delivery report
Content-Type: message/delivery-status

Reporting-MTA: dns; newmail.codefab.com
X-Postfix-Queue-ID: 9AC7412265B70
X-Postfix-Sender: rfc822; cswi...@mac.com
Arrival-Date: Thu,  5 Apr 2012 11:48:59 -0400 (EDT)

Final-Recipient: rfc822; uh...@fantomas.sk
Original-Recipient: rfc822;uh...@fantomas.sk
Action: failed
Status: 5.7.1
Remote-MTA: dns; fantomas.fantomas.sk
Diagnostic-Code: smtp; 550 5.7.1 uh...@fantomas.sk... Your domain does not
have a working abuse address. This violates RFC 2142 - see

http://www.rfc-ignorant.org/tools/lookup.php?domain=rrcs-24-103-228-244.nyc.biz.rr.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: BIND Lameness

[Chuck Swiger]

On 4/2/2012 10:37 PM, Keith Burgoyne wrote:
[ ... ]

I've recently replaced the master server at 24.222.7.11, and am now running
bind 9.7.3.

My question is: I keep seeing log entries like

Apr 2 23:24:17 clementine named[5870]: lame server resolving
'comuna.silverorange.com' (in 'silverorange.com'?): 24.222.7.12#53
Apr 2 23:24:01 clementine named[5870]: lame server resolving 'veseys.com' (in
'veseys.com'?): 24.222.7.12#53

and the list goes on. I don't get a lot, probably a few a minute. But where do
they come from?


Does the following help:

  http://www.dnsvalidation.com/reports/4f7a96b37d79ee376912
  http://www.dnsvalidation.com/reports/4f7a97bd7d79ee3d420c

ns3.silverorange.com seems to be down, and the other two nameservers being 
listed aren't responding to TCP port 53.


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

[Chuck Swiger]

On 4/3/2012 10:14 AM, Barry Margolin wrote:

In articlemailman.419.1333434497.63724.bind-us...@lists.isc.org,
  Chuck Swigercswi...@mac.com  wrote:

[ ... ]

Does the following help:

http://www.dnsvalidation.com/reports/4f7a96b37d79ee376912
http://www.dnsvalidation.com/reports/4f7a97bd7d79ee3d420c

ns3.silverorange.com seems to be down, and the other two nameservers being


Since the log message is specifically about ns1, how could ns3's status
be relevant?


It wouldn't be, but you've already figured that out yourself.


listed aren't responding to TCP port 53.


Why would clementine be trying TCP?  His server appears to support
EDNS0, so it shouldn't need it.

I'm not saying this isn't a problem, but I don't think it would cause
this symptom.


If clementine sent a TCP query to what it believes was an authoritative 
nameserver, and got no response, that might explain the lame delegation 
warnings, regardless of whether a EDNS0 query via UDP works or not.


Yet your point here explains my initial response: there are times when solving 
a symptom is still useful, but it's generally more helpful to solve the root 
cause.  Oh, it might not be the case that fixing ns3 and making sure that all 
of the nameservers work over both TCP and UDP port 53 will resolve the lame 
delegation messages, but I'd start with fixing things which are obviously 
broken first, and then recheck whether than fixes the delegation warning as 
well...


Regards,
--
-Chuck

___
Please visit https://lists.isc.org/mailman/listinfo/bind-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 reset the serial number?

[Chuck Swiger]

On Mar 26, 2012, at 11:30 AM, Carlos Ribas wrote:
 I accidentally changed the serial number to one bigger than 32 bits and now 
 I'm trying to reset the serial number. Following the manual of Bind9 I tried 
 to add 2147483647 (2ˆ31-1) to the number and reload the server, but my slave 
 is not updating to the new zone serial number.

Shut down the slave server(s).
Use scp or rsync to copy over the zone file, one with a corrected serial #.
Restart the slave server(s).

[ Is BIND putting SOA serial #'s into a signed int? ]

Regards,
-- 
-Chuck

___
Please visit https://lists.isc.org/mailman/listinfo/bind-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 requests error sending response: host unreachable

[Chuck Swiger]

On Mar 12, 2012, at 8:09 AM, Romgo wrote:
 Dear community,
 
 I do have many error in my Bind's log file such as :
 
 client 192.168.201.1#29404: error sending response: host unreachable
 
 It seems that I have an iptables issue as each time I shut iptables I don't 
 have anymore this message showing up.

You're probably exhausting the firewall state table with DNS traffic under 
load, causing the traffic to be blocked with an ICMP host unreachable 
response.

 I saw that my firewall is dropping packets from the DNS server itself towards 
 the client, as the source port is SPT=53/UDP.
 
 I am using bind 9.6, it should use random port 1024 for the source port. (I 
 didn't specify query-source parameter).
 
 Nevertheless dns resolution seems to be working find.

Adjust your firewall to permit UDP and TCP traffic needed for DNS without 
keeping state, or only keep state on external traffic, but not between your 
nameserver(s) and your local clients...

Regards,
-- 
-Chuck

___
Please visit https://lists.isc.org/mailman/listinfo/bind-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 requests error sending response: host unreachable

[Chuck Swiger]

On Mar 12, 2012, at 1:24 PM, Romgo wrote:
 Here is my Iptables configuration for bind :
 
 # prod.dns.in
 $IPTABLES -t filter -A INPUT -j LOGACCEPT -p udp --dport 53 -i eth1-d 
 192.168.201.2 -s 0/0
 $IPTABLES -t filter -A INPUT -j LOGACCEPT -p tcp --dport 53 -i eth1 -d 
 192.168.201.2 -s 0/0

Shouldn't the first line have a space before the minus within eth1-d?

Regards,
-- 
-Chuck

___
Please visit https://lists.isc.org/mailman/listinfo/bind-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's wrong with the e.hushpuppies-australia.com delegation @ns.domainnetwork.se ?

[Chuck Swiger]

Hi--

On Feb 27, 2012, at 12:14 PM, M. Meadows wrote:
 But
  
 dig e.hushpuppies-australia.com +nssearch @8.8.8.8
  
 Yields no nameserver list.

+nssearch does SOA lookups for each of the nameservers, but 
ns.domainnetwork.se (and so forth) only returns an SOA record for 
hushpuppies-australia.com and not e.hushpuppies-australia.com:

% dig -t soa hushpuppies-australia.com. @ns.domainnetwork.se
;  DiG 9.6-ESV-R4-P3  -t soa hushpuppies-australia.com. 
@ns.domainnetwork.se
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 2169
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;hushpuppies-australia.com. IN  SOA

;; ANSWER SECTION:
hushpuppies-australia.com. 86400 IN SOA ns.domainnetwork.se. 
hostmaster.melbourneitcbs.com. 2012022200 28800 7200 1209600 86400

;; Query time: 96 msec
;; SERVER: 203.27.227.61#53(203.27.227.61)
;; WHEN: Mon Feb 27 15:27:24 2012
;; MSG SIZE  rcvd: 124

% dig -t soa e.hushpuppies-australia.com. @ns.domainnetwork.se
;  DiG 9.6-ESV-R4-P3  -t soa e.hushpuppies-australia.com. 
@ns.domainnetwork.se
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 56060
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;e.hushpuppies-australia.com.   IN  SOA

;; AUTHORITY SECTION:
e.hushpuppies-australia.com. 600 IN NS  ns1.exacttarget.com.
e.hushpuppies-australia.com. 600 IN NS  ns2.exacttarget.com.

;; Query time: 97 msec
;; SERVER: 203.27.227.61#53(203.27.227.61)
;; WHEN: Mon Feb 27 15:27:28 2012
;; MSG SIZE  rcvd: 93

Also notice that the nameservers listed in WHOIS (ie, ns*.domainnetwork.se) 
don't match ns*.exacttarget.com; you're missing several glue records as far as 
*.gtld-servers.net are concerned.

Regards,
-- 
-Chuck


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

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

Re: Query Regarding AKAMAI Working Model

[Chuck Swiger]

Hi, Gaurav--

On Feb 17, 2012, at 11:15 AM, Gaurav kansal wrote:
 I want to know how AKAMAI works

They work well.  :-)

 May be this is not the right forum to ask but I am asking this here because 
 AKAMAI heavily depend on its HL-DNS and LL-DNS  AND these DNS Servers answer 
 the query based on some input it gets from BGP Routes.

They've got a fair amount of documentation publicly available describing their 
CDN network, pushing updates from origin to their Edge servers, Akamai'zed URL 
format, determining which Edge servers should be returned for a client request, 
based on geo location, network location, availability and throughput, failover, 
and so forth.

  http://www.akamai.com/html/technology/products/index.html

It's not completely off-topic, but you'd likely do better to ask them directly 
if you need more info.

Regards,
-- 
-Chuck

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

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

Re: Efficacy of using short timeout values for an A record

[Chuck Swiger]

On Feb 14, 2012, at 11:11 AM, Alan Clegg wrote:
 On 2/14/2012 1:42 PM, Chuck Swiger wrote:
 
 ISC's BIND has (or had) a MINTTL value of 5 minutes / 300 seconds.
 It's probably unreasonable to expect other platforms to refetch DNS
 records faster than that.
 
 Uh... no.  BIND has always respected TTL when caching information.

See http://www.ietf.org/rfc/rfc1035.txt

The MINIMUM value in the SOA should be used to set a floor on the TTL of
data distributed from a zone.  This floor function should be done when
the data is copied into a response.  This will allow future dynamic
update protocols to change the SOA MINIMUM field without ambiguous
semantics.

...and lib/dns/master.c dns_soa_getminimum() and limit_ttl().  At one point,
and I might be dating myself back to the BIND-4.x days, these used to set
a minimum floor value of 300 seconds, even if the SOA or per-record TTL was
smaller.

Maybe that is no longer the case in BIND-9.x and more common use of dynamic
updates, but I repeat my observation that it's not reasonable to update DNS
at sub-minute intervals and expect all clients to honor such

Regards,
-- 
-Chuck

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

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

Re: Efficacy of using short timeout values for an A record

[Chuck Swiger]

On Feb 14, 2012, at 2:16 PM, Mark Andrews wrote:
 ISC's BIND has (or had) a MINTTL value of 5 minutes / 300 seconds.
 It's probably unreasonable to expect other platforms to refetch DNS
 records faster than that.
 
 To the best of my knowlege this is just plain wrong. 

Look at BIND-4.8.3 and check named/db_update.c around line 40:

int min_cache_ttl = (5*60); /* 5 minute minimum ttl */

...and then:

fixttl(dp)
register struct databuf *dp;
{
if (dp-d_zone == 0  !(dp-d_flags  DB_F_HINT)) {
if (dp-d_ttl = tt.tv_sec)
return;
else if (dp-d_ttl  tt.tv_sec+min_cache_ttl)
dp-d_ttl = tt.tv_sec+min_cache_ttl;
else if (dp-d_ttl  tt.tv_sec+max_cache_ttl)
dp-d_ttl = tt.tv_sec+max_cache_ttl;
}
return;
}

...or check named/ns_req.c around line 720 for the equivalent for a secondary 
NS:

if (dp-d_ttl)
ttl = dp-d_ttl;
else
ttl = zp-z_minimum;/* really default */
#ifdef notdef /* don't decrease ttl based on time since verification */
if (zp-z_type == Z_SECONDARY) {
/*
 * Set ttl to value received from primary,
 * less time since we verified it (but never
 * less than a small positive value).
 */
ttl -= tt.tv_sec - zp-z_lastupdate;
if (ttl = 0)
ttl = 120;
}
#endif

Regards,
-- 
-Chuck

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

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

Re: Forward Domain

[Chuck Swiger]

On Jan 15, 2012, at 8:41 AM, Markus Braun wrote:
  DNSMASQ is basically a DNS forwarder but it has a bunch of other
  features. Check the Wikipedia page on it and if you have questions
  please ask on their mailing list or forum.
  
  Regarding BIND, if you have issues with your server returning some
  results within your server and other results when queried from the
  outside you should take a look at BIND views.
  
  Please invest some time studying BIND, at least the basics to run a
  caching nameservers. You'll need that.
 
 i googled the last daysi cant run DNSMASQ and BIND9 both on the same port 
 or?

Nope.  Most services are terribly selfish and will not let
other services bind to the same port which they are using.

 i though it is easy to create a forward under bind9.

It is easy to forward requests to another nameserver under BIND.

Like the person you just replied to said, I suspect that you mean
something else by the word, which BIND also provides via views.

 caching nameservers? can you give some more details please?

Read the docs.  Or RFC-1034.  Or go pick up DNS and BIND from O'Reilly.

Trying to run a nameserver without any background knowledge is roughly
comparable to trying to drive a car with a blindfold on.  It's less a
question of will you crash and break things? and more a question of
how quickly will you crash, how many things get broken, and how many
other people are going to be affected as a consequence...?

Regards,
-- 
-Chuck

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

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

Re: best practices for two-location DDNS for a single domain

[Chuck Swiger]

Hi--

On Jan 12, 2012, at 5:04 PM, Chris McCraw wrote:
 But those aren't an option here - they both need to serve the same
 domain and both need to allow local DDNS updates visible from both
 sides, and work in the absence of a network between the two.  I've
 done some searching and it does not appear that BIND fully supports
 this setup natively.  Please correct me if I'm wrong!

I'm not sure that anything will fully solve your requirements as stated.

The normal implementation of a fault-tolerant system requires a single master 
server, and the backups simply write through changes they see back to that 
master.  If the master drops out, then a backup promotes itself to master, but 
the old master needs to no longer be accepting updates.  Trying to update two 
masters without some kind of network link available between them means you've 
created a split horizon [1], and they will move out of sync with each other as 
they get updates which the other side(s) doesn't/don't see.

 I found a potential workaround using a dual-master setup with some
 magic to manually sync the updates back and forth, but that magic
 seems like it might end up being fragile.

Yeah, fragile meaning it will fail if the link between them drops out and a 
conflicting update is received which cannot be reconciled with the other 
side(s).

Regards,
-- 
-Chuck

[1]: split horizon in the terminology of cluster failover; not split horizon 
DNS meaning views based upon (ie) request source address.

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

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

Re: About root zones

[Chuck Swiger]

On Jan 3, 2012, at 11:13 AM, Peter Andreev wrote:
 Unfortunately as I learning BIND more, I understand that it is not
 very suitable for my requirements.

Which are?  I've been trying to understand what the actual problem you are 
trying to solve might be.

Regards,
-- 
-Chuck

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

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

Re: About root zones

[Chuck Swiger]

On Jan 2, 2012, at 2:16 PM, Barry Margolin wrote:
 If the system resolver is good enough for every other application 
 running on the system, it should be good enough for BIND.
 
 Why not at least allow this as an option?

The system resolver will happily provide answers based upon data from 
/etc/hosts, YP/NIS, and LDAP which have no relationship to what is in the DNS.

Every other application on the system is probably not a DNS nameserver.  Case 
in point: should dig use the system resolver for an /etc/hosts entry and 
pretend that there was an A and PTR record in the DNS?

Regards,
-- 
-Chuck

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

[Chuck Swiger]

Hi--

On Oct 17, 2011, at 3:37 PM, Karl Auer wrote:
 To see it, do (for example):
 
   dig+trace biplane.com.au ns
 
 Some such queries return correctly, some end up in a BHR loop.

I don't see a bad horizontal referral being returned anywhere, but I do get 
errors against ppsdns6.pps.com.au since that appears to be an IPv6 only 
nameserver:

% dig +trace biplane.com.au ns  


;  DiG 9.6.0-APPLE-P2  +trace biplane.com.au ns
;; global options: +cmd
[ ... ]
;; Received 412 bytes from 58.65.253.73#53(b.au) in 89 ms

biplane.com.au. 14400   IN  NS  ppsdns6.pps.com.au.
biplane.com.au. 14400   IN  NS  ppsdns2.pps.com.au.
biplane.com.au. 14400   IN  NS  ppsdns1.pps.com.au.
biplane.com.au. 14400   IN  NS  ppsdns4.pps.com.au.
;; Received 184 bytes from 69.36.146.34#53(o.au) in 108 ms

dig: couldn't get address for 'ppsdns6.pps.com.au': not found

I don't believe the world is ready for IPv6-only nameservers, but YMMV:

  http://www.dnsvalidation.com/reports/4e9cb0d37d79ee5fbe08

Regards,
-- 
-Chuck

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

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

Re: fallback to forwarder if master zone does not have requested record

[Chuck Swiger]

On Oct 13, 2011, at 7:57 AM, Moser, Stefan (SIDB) wrote:
 in customer migrations, when we shift customers from an old DNS environment 
 to a new DNS environment, there are sometimes situations where we have to 
 keep the same domain (let’s say “example.com”) both on the old DNS-server and 
 on the new DNS-server. E.g., there was an A record “mail.example.com” on the 
 old DNS-server “dns-old”, and an A record “sap.example.com” on the new 
 DNS-Server “dns-new”. It would be beneficial, if DNS-clients of “dns-new” 
 could resolve both “mail.example.com” and “sap.example.com”, across both 
 DNS-servers.

One could do this by having dns-old switch to being a slave of the zone from 
dns-new.

Or remove any trace of configuration of example.com zone from dns-old, and 
clients talking to dns-old will have it perform recursive resolution of the 
domain which will get data from dns-new, just as it would for any other 
random domain.

 I can’t think of a meaningful BIND configuration to “mix” both zones, because 
 of the inherent zone / authoritative model that DNS and BIND have and that 
 makes forwarders, masters and slaves mutually exclusive. What would be needed 
 was some kind of “fallback forwarder” that would forward requests it cannot 
 find in a zone that it is authoritative for.

Um, yeah.  If you configure a nameserver to be authoritative for a zone, then 
that zone needs to have every valid record.  If an authoritative nameserver 
doesn't have all valid records, someone is doing it wrong.

Regards,
-- 
-Chuck

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

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

Re: One IP in multiple zones

[Chuck Swiger]

On Sep 21, 2011, at 12:56 PM, Adamiec, Lawrence wrote:
 Is it possible to have one IP in multiple zone files for forward lookups?

Yes.

 What type of troubles would be encountered?

None.  This sort of thing is very commonly done, for example with 
shared/virtual webservers.

Regards
-- 
-Chuck

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

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

Re: blacklisting replies, was: Proper CNAME interpretation

[Chuck Swiger]

On Sep 14, 2011, at 5:09 PM, Ronald F. Guilmette wrote:
 In message cf550bd6-ba85-4cb3-8b03-e4e1b0829...@mac.com, you wrote:
 Sigh: your mail server is blacklisting email from mac.com.
 
 Yes.  Sorry about that.  Too much spam from there and no indication
 that anybody there gives a damn that that they gush spam.  (If you
 find anybody who does care, please le me know via the contact form on
 my web site.)

Being an RFC-2142 contact for a large domain is a never-ending, often thankless 
labor worthy of Sisyphus. [1]

 Anyway, on-list replies are OK, I think.  I mean it's not like any of
 this is in any way off topic.

This mailing list seems to be using GNU Mailman, which generally will try to 
avoid sending an extra copy of list traffic if it notices that a recipient is 
also To: or CC:ed directly.  However, if the copy sent directly bounced, then 
it would be entirely possible that you'd never see the reply, even though the 
rest of the list would receive it.

 In other words, if you ask for an A record, and you get back both a CNAME and
 an A record, then the A record matches and that's what 
 gethostbyname()/getaddrinfo()
 or whatever should receive from the resolver.
 
 OK. That much _is_ clear from the above RFC quote.
 
 But then if that _is_ supposed to be true, then why is nslookup all of a
 sudden balking and not printing _any_ IP address for graphiteops.com
 today?

nslookup has been deprecated for some time, because it isn't a particularly 
good tool for diagnosing DNS issues.  dig is much better.

 My local name server has _both_ a CNAME _and_ an A record cached
 for that... at least that is what appears to be the case when I check
 locally using:
 
   dig graphiteops.com any @127.0.0.1
 
 When I do that I get back:
 
   ...
   graphiteops.com.21131   IN  A   72.52.4.95
   graphiteops.com.3131IN  CNAME   graphiteops.com.
   ...

dig is appears to be doing the right thing, here.  It's returning all of the 
records which match, and since it does find non-CNAME matches, it doesn't chase 
the CNAME.

 So under these circumstances, nslookup really should be printing out the
 address (72.52.4.95) which I just simply do nslookup graphiteops.com, no?
 But it ain't doing that.
 
 Also very puzzling is what I get when I just do:
 
dig graphiteops.com a @127.0.0.1
 
 In this case I only get back the CNAME record, and the A record doesn't even
 appear in the dig output !?!?!  So what's up with that???

I don't see that here; asking for an A record against a local nameserver gives 
me an A record back:

% dig graphiteops.com a @127.0.0.1

;  DiG 9.6.0-APPLE-P2  graphiteops.com a @127.0.0.1
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 21530
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 8

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

;; ANSWER SECTION:
graphiteops.com.21593   IN  A   72.52.4.95

;; AUTHORITY SECTION:
[ ... ]

 If you asked for an  record, and got that same reply of a CNAME and an A 
 record,
 then the resolver should chase the CNAME's data field.
 
 Yes.  That part makes sense, and is abundantly clear from the RFC passage you
 quoted.  In short, I agree, and this is, and has been, an enlightening ex-
 change for me.  So thank you for that.

OK.

 Now, if I can just figure out why my local dig and nslookup seem to be pro-
 ducing such nonsensical (and non-standard?) results, I'll be a happy man.

Give up trying to debug DNS using nslookup, and just use dig.

 It sure _sounds_ like that second sentence is encouraging any  all people
 who are writing resolvers, or other related tools, that they should ignore
 any flotsam  jetsum that appear along side a CNAME.
 ...
 By no means.  You only ought to chase a CNAME if you got a CNAME *instead*
 of the resource type that you asked for.
 
 Yea.  I see now, and understand.  (And thanks again.)
 
 But as I say, my local dig  nslookup _do not_ seem to understand.  In fact
 they both seem to be misbehaving rather significantly, and I don't understand
 that at all.

I wonder if something changed in the handling of CNAME loops between BIND-9.5 
and later versions?

 P.S.  Curiously, I am getting the exact same odd results out of dig, even
 when I force it to directly query one of the authoritative servers for the
 graphiteops.com domain.  So, for example:
 
   dig graphiteops.com a @pdns1.ultradns.net
 
 only shows me the CNAME... no A record!  Whereas:

You're getting strange results back from pdns1.ultradns.net; it's not dig, it's 
what they return.

Most of the other nameservers listed as responsible for the domain don't even 
return the expected glue records indicating that they know that they're 
authoritative for it, and that CNAME loop causes simple things like looking up 
the SOA record to give you the CNAME back, instead:

  http://www.dnsvalidation.com/reports/4e7236047d79ee3a740a

   dig graphiteops.com 

Re: Proper CNAME interpretation

[Chuck Swiger]

On Sep 14, 2011, at 2:27 PM, Ronald F. Guilmette wrote:
 The second part however seems to go more to my question, which is What is
 the resolver supposed to do when some knucklehead breaks the rules and puts
 a CNAME in with some other stuff?

Depends on which query one issued.  The very next paragraph of RFC-1034 is:

CNAME RRs cause special action in DNS software.  When a name server
fails to find a desired RR in the resource set associated with the
domain name, it checks to see if the resource set consists of a CNAME
record with a matching class.  If so, the name server includes the CNAME
record in the response and restarts the query at the domain name
specified in the data field of the CNAME record.  The one exception to
this rule is that queries which match the CNAME type are not restarted.

In other words, if you ask for an A record, and you get back both a CNAME and 
an A record, then the A record matches and that's what 
gethostbyname()/getaddrinfo() or whatever should receive from the resolver.  If 
you asked for an  record, and got that same reply of a CNAME and an A 
record, then the resolver should chase the CNAME's data field.

 It sure _sounds_ like that second sentence is encouraging any  all people
 who are writing resolvers, or other related tools, that they should ignore
 any flotsam  jetsum that appear along side a CNAME.  But is that encourage-
 ment espressed anywhere as a MUST?

By no means.  You only ought to chase a CNAME if you got a CNAME *instead* of 
the resource type that you asked for.

Regards,
-- 
-Chuck

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

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

blacklisting replies, was: Proper CNAME interpretation

[Chuck Swiger]

Sigh: your mail server is blacklisting email from mac.com.

Begin forwarded message:
 From: postmas...@mac.com
 Date: September 14, 2011 2:53:05 PM PDT
 To: cswi...@mac.com
 Subject: Delivery Notification: Delivery has failed
 
 This report relates to a message you sent with the following header fields:
 
  Message-id: 2be47d87-8417-4055-8466-f47cd7fdb...@mac.com
  Date: Wed, 14 Sep 2011 14:52:34 -0700
  From: Chuck Swiger cswi...@mac.com
  To: Ronald F. Guilmette r...@tristatelogic.com
  Subject: Re: Proper CNAME interpretation
 
 Your message cannot be delivered to the following recipients:
 
  Recipient address: r...@tristatelogic.com
  Reason: Remote SMTP server has rejected address
  Diagnostic code: smtp;550 5.7.1 asmtpout025.mac.com: Helo command 
 rejected: Domain mac.com BLACKLISTED - Use 
 http://www.tristatelogic.com/contact.html
  Remote system: dns;server1.tristatelogic.com 
 (TCP|17.148.16.100|49837|69.62.255.118|25) (segfault.tristatelogic.com ESMTP 
 Postfix [2.5.3])
 
 Reporting-MTA: dns;asmtp025-bge351000.mac.com (tcp-daemon)
 Arrival-date: Wed, 14 Sep 2011 14:52:35 -0700 (PDT)
 
 Original-recipient: rfc822;r...@tristatelogic.com
 Final-recipient: rfc822;r...@tristatelogic.com
 Action: failed
 Status: 5.7.1 (Remote SMTP server has rejected address)
 Remote-MTA: dns;server1.tristatelogic.com
 (TCP|17.148.16.100|49837|69.62.255.118|25)
 (segfault.tristatelogic.com ESMTP Postfix [2.5.3])
 Diagnostic-code: smtp;550 5.7.1 asmtpout025.mac.com: Helo command rejected:
 Domain mac.com BLACKLISTED - Use http://www.tristatelogic.com/contact.html
 
 From: Chuck Swiger cswi...@mac.com
 Date: September 14, 2011 2:52:34 PM PDT
 To: Ronald F. Guilmette r...@tristatelogic.com
 Cc: bind-users@lists.isc.org
 Subject: Re: Proper CNAME interpretation
 
 
 On Sep 14, 2011, at 2:27 PM, Ronald F. Guilmette wrote:
 The second part however seems to go more to my question, which is What is
 the resolver supposed to do when some knucklehead breaks the rules and puts
 a CNAME in with some other stuff?
 
 Depends on which query one issued.  The very next paragraph of RFC-1034 is:
 
 CNAME RRs cause special action in DNS software.  When a name server
 fails to find a desired RR in the resource set associated with the
 domain name, it checks to see if the resource set consists of a CNAME
 record with a matching class.  If so, the name server includes the CNAME
 record in the response and restarts the query at the domain name
 specified in the data field of the CNAME record.  The one exception to
 this rule is that queries which match the CNAME type are not restarted.
 
 In other words, if you ask for an A record, and you get back both a CNAME and 
 an A record, then the A record matches and that's what 
 gethostbyname()/getaddrinfo() or whatever should receive from the resolver.  
 If you asked for an  record, and got that same reply of a CNAME and an A 
 record, then the resolver should chase the CNAME's data field.
 
 It sure _sounds_ like that second sentence is encouraging any  all people
 who are writing resolvers, or other related tools, that they should ignore
 any flotsam  jetsum that appear along side a CNAME.  But is that encourage-
 ment espressed anywhere as a MUST?
 
 By no means.  You only ought to chase a CNAME if you got a CNAME *instead* of 
 the resource type that you asked for.
 
 Regards,
 -- 
 -Chuck
 
 
 

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

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

Re: Memory utilisation problem on busy bind resolver

[Chuck Swiger]

Hi, Dennis--

On Aug 9, 2011, at 7:31 AM, Dennis Perisa wrote:
 We are running a number of BIND 9.7.3-p3 caching nameservers.  In the
 last couple of months, we've observed the memory utilisation of named
 increasing at a steady rate of 1-2% per day on our busiest resolver
 with no indication of subsiding - on occasion, there have been large
 step increases of 1 GB or so.

Yeah, I've seen similar things on machines used to perform DNS resolution of 
busy webserver logfiles-- seemed like BIND-9.4 (.4.ESV.4) was ignoring 
max-cache-size setting entirely, but BIND-9.6.x seemed to do OK.  I wonder if 
there's a regression with BIND-9.7.x?

 All our other resolvers are configured identically but are behaving
 themselves with memory utilisation remaining at fairly constant
 levels.
 
 I've looked at all the named logs until my eyeballs have almost fallen
 out of my head but am unable to determine the cause of this.  So I'm
 taking a step back and hoping to get some advice - what else can I do
 to find the cause of this?  Or is it something I simply need to live
 with?

It could be anything from memory leaks in named or the system libraries like 
libc, to a bug in named not honoring the cache size settings.  Does a cache 
flush actually help reduce VM usage of named in your case?

You haven't mentioned which platform you are using, but looking for leaks can 
involve anything from env MALLOC_OPTIONS='U' ktrace named for many BSD 
flavors, leaks named for OS X, mtrace() for GNU libc, to recompiling named 
and the libraries using Valgrind/Purify/etc.

Or, one can also use gdb attach to a running named and try to see the current 
state of the cache and so forth; someone from ISC who is more familiar with the 
exact code there can probably give more specific debugging hints.

 We're looking at measures such as periodic cache flushes, and tuning
 max-cache-size, max-cache-ttl and max-cache-nttl params to limit
 memory usage, but this may only be treating the symptom and costs us
 extra cpu cycles.

I hear this-- in my prior case, tuning max-cache-size, recursive-clients, etc 
didn't make any difference...

Regards,
-- 
-Chuck

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

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

Re: epza.gov.tw. MX

[Chuck Swiger]

Hi--

On Aug 8, 2011, at 1:15 PM, Mark K. Pettit wrote:
 My resolvers, running BIND 9.7.3P3, are having a difficult time resolving the 
 MX record for the zone epza.gov.tw..
[ ... ]
 But if I query any of [abc].twnic.net.tw. directly for the IP address of 
 dns.epza.gov.tw, I get an answer.  Example:
[ ... ]
 It appears to me that BIND is seeing this response, and then ignoring the IP 
 in the Additional section.
 
 Any idea why this might be happening?

The trace I get here shows:

;; Received 191 bytes from 211.79.207.26#53(e.dns.tw) in 221 ms

epza.gov.tw.43200   IN  NS  dns.epza.gov.tw.
;; Received 63 bytes from 168.95.192.10#53(c.twnic.net.tw) in 213 ms

dig: couldn't get address for 'dns.epza.gov.tw': not found

It looks like Google's public nameservers chase a CNAME when you ask for an A 
record, but I thought nameservers listed in NS records should have a 
corresponding A record and _not_ a CNAME.  Compare versus the level-3 
nameservers, which get a SERVFAIL:

% dig dns.epza.gov.tw @8.8.8.8
;  DiG 9.6.0-APPLE-P2  dns.epza.gov.tw @8.8.8.8
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 40236
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dns.epza.gov.tw.   IN  A

;; ANSWER SECTION:
dns.epza.gov.tw.3600IN  CNAME   ns.epza.gov.tw.
ns.epza.gov.tw. 3600IN  A   163.29.43.1

;; Query time: 439 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Aug  8 16:25:36 2011
;; MSG SIZE  rcvd: 66

% dig dns.epza.gov.tw @4.2.2.1
;  DiG 9.6.0-APPLE-P2  dns.epza.gov.tw @4.2.2.1
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 10484
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dns.epza.gov.tw.   IN  A

;; Query time: 11 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Mon Aug  8 16:29:37 2011
;; MSG SIZE  rcvd: 33

Regards,
-- 
-Chuck

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

[Chuck Swiger]

On Jul 21, 2011, at 3:02 PM, Sathyan Arjunan (sarjunan) [CONTRACTOR] wrote:
 Recent days, I am facing frequent caching issues with my DNS servers which 
 are responsible for recursive lookup to external queries. As a temporary 
 solution, we used to refresh the named daemon to clear the cache. To isolate 
 this issue we upgraded the BIND to “BIND 9.7.3” but even after the upgrade 
 issue repeats. Any thoughts?

BIND is intended to perform caching according to the TTLs of the resources.  
You'll have to provide more details about what you think is wrong

Regards,
-- 
-Chuck

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

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

Re: Reverse lookup flood from a single host

[Chuck Swiger]

On Jul 15, 2011, at 12:24 PM, Joshua Beard wrote:
 Greetings,
 
 I've noticed a specific client machine doing a crap load of reverse lookups 
 in my named logs.  It's just reverse lookups for our internal network, and 
 just from that machine.  I can't see that this machine is looking up anything 
 else, actually.  Here's an example:
 11-Jul-2011 08:11:00.997 client 172.30.116.116#53: view dsdk12.schoollocal: 
 query: 99.115.30.172.in-addr.arpa IN PTR + (172.30.112.121)
 11-Jul-2011 08:11:01.116 client 172.30.116.116#53: view dsdk12.schoollocal: 
 query: 75.241.40.208.in-addr.arpa IN PTR + (172.30.112.121)
 11-Jul-2011 08:11:01.392 client 172.30.116.116#53: view dsdk12.schoollocal: 
 query: 1.162.30.172.in-addr.arpa IN PTR + (172.30.112.121)
 11-Jul-2011 08:11:01.393 client 172.30.116.116#53: view dsdk12.schoollocal: 
 query: 150.160.30.172.in-addr.arpa IN PTR + (172.30.112.121)
 11-Jul-2011 08:11:01.590 client 172.30.116.116#53: view dsdk12.schoollocal: 
 query: 25.96.30.172.in-addr.arpa IN PTR + (172.30.112.121)
 11-Jul-2011 08:11:01.680 client 172.30.116.116#53: view dsdk12.schoollocal: 
 query: 2.130.30.172.in-addr.arpa IN PTR + (172.30.112.121)
 11-Jul-2011 08:11:01.940 client 172.30.116.116#53: view dsdk12.schoollocal: 
 query: 40.207.115.66.in-addr.arpa IN PTR + (172.30.112.121)
 11-Jul-2011 08:11:01.940 client 172.30.116.116#53: view dsdk12.schoollocal: 
 query: 22.114.30.172.in-addr.arpa IN PTR + (172.30.112.121)
 11-Jul-2011 08:11:02.588 client 172.30.116.116#53: view dsdk12.schoollocal: 
 query: 55.98.30.172.in-addr.arpa IN PTR + (172.30.112.121)
 11-Jul-2011 08:11:02.785 client 172.30.116.116#53: view dsdk12.schoollocal: 
 query: 179.112.30.172.in-addr.arpa IN PTR + (172.30.112.121)
 11-Jul-2011 08:11:02.786 client 172.30.116.116#53: view dsdk12.schoollocal: 
 query: 105.248.250.17.in-addr.arpa IN PTR + (172.30.112.121)
 
 It appears to be non-stop.  Middle of the night and through the day.  I don't 
 have physical access to the machine at this time, so I can't investigate too 
 much.
 
 Is this abuse?  If so, is it likely intentional?

Given that the client is using a RFC-1918 unrouteable IP, presumably it's local 
to your network.  

The data you've shown is less than 10 queries per second; whether this is 
abusive depends on your policies, but it's not a high query rate.  It wouldn't 
surprise me if a webserver log analysis program like analog/Unison/webalyzer or 
a virus/malware scanner would generate such traffic.

Regards,
-- 
-Chuck

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

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

Re: Clients get DNS timeouts because ipv6 means more queries for each lookup

[Chuck Swiger]

On Jul 11, 2011, at 1:25 PM, Jonathan Kamens wrote:
 Even if PowerDNS is the only source of this issue, and even if the new 
 version of PowerDNS is released tomorrow, I'm sure there will still be sites 
 running the old version a year from now. So just relying on a PowerDNS 
 release to fix this problem seems unwise.

OK, but this same reasoning applies to making a change to BIND: even if we had 
such a change available tomorrow, there will be sites running older versions of 
BIND a year from now, also.  :-)

 Users are experiencing this problem now in the field, and more users will be 
 experiencing it as BIND is upgraded in more and more places. Every single 
 user relying on a Fedora 15 DNS server, for example, is going to see 
 occasional unnecessary DNS timeouts when trying to resolve host names.
 
 It seems clear to me that a generally available, generally applicable fix to 
 BIND is needed to avoid this issue and perhaps similar issues like it.

What you probably want is a change to your local implementation of 
getaddrinfo() for your libc / glibc so that it prefers to issue T_A queries 
before it issues T_ queries, and will only issue T_ queries if IPv6 
networking is compiled into the system.

In my experience, not only does this significantly help resolver performance in 
the face of nameservers which break when facing IPv6  queries, it is a 
solution which many people ignore.

  http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=42405

Regards,
-- 
-Chuck

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

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

Re: Logging Response Results

[Chuck Swiger]

On Jun 23, 2011, at 12:16 PM, Stefan Certic wrote:
 Does anyone have idea on following... Apart from bind9 query log, is it 
 possible to log response returned to client?

Sure: use tcpdump, wireshark, or another network sniffer of your choice and 
observe DNS responses to the clients you're interested in.  (Whether this is 
better than using query logging is another question entirely.)

Regards,
-- 
-Chuck

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

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

Re: Logging Response Results

[Chuck Swiger]

On Jun 23, 2011, at 1:27 PM, Stefan Certic wrote:
 Thanks Chuck
 
 Yes, that would be a solution, but i need logs processed through syslog and 
 stored into database (matching the initial query from query log).

Why do you need to send this information via syslog to a database?

 Pharsing tcpdump is not going to be suitable for highly loaded system. I was 
 more looking for a solution to log responses same way queryes are logged.

Parsing tcpdump doesn't constitute much work; I've got scripts which deal with 
NTP traffic at 500 - 2000+ requests per second without consuming much 
resources...although monitoring NTP takes noticeably more work than ntpd itself 
needs to provide time.

It's the other requirements being added which strike me as heavy-weight.

Regards,
-- 
-Chuck

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

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

Re: Logging Response Results

[Chuck Swiger]

On Jun 23, 2011, at 2:28 PM, Stefan Certic wrote:
 It is Enum server, and logging is taking care of billing process.

I don't see why you need to preserve queries and responses, unless you plan to 
charge differently for different DNS requests.  Can't you just track traffic 
per client using netflow records, firewall counters, etc?

Also, it's hard to beat free-- and there are plenty of freely available DNS 
servers around.

Regards,
-- 
-Chuck

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

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

Re: Bind9 Random Whois and Dig Fails

[Chuck Swiger]

On Jun 7, 2011, at 11:07 AM, Sri Harsha Yalamanchili wrote:
 Not much luck using tcpdump either. We know, from both the query_log and 
 tcpdump logging, that the queries are going out. But we never get a reply 
 back. That's the confusing part. The Google DNS server replies back but not 
 our own ISP's DNS. It times out multiple times before replying once if at all.

It sounds like this Telepacific nameserver at IP 66.7.224.17 is broken.  The 
simple solution is to not use any forwarders entry, or to pick another one 
which works.

Regards,
-- 
-Chuck

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

Re: dnssec-keygen with different activation date

[Chuck Swiger]

On May 20, 2011, at 4:41 PM, Noel Rocha wrote:
 # Showing activate date
 $ cat Kmydomain.com.+005+48738.key | grep Activate
 ; Activate: 20110520203500 (Fri May 20 17:35:00 2011)
 
 This (20110520203500)2011/05/20 20:35:00 isn't Fri May 20 17:35:00 2011. :(
 
 Anyone have idea how to solve this problem?

There isn't a problem: 20:35 GMT is 17:35 BRT.

As a general rule, ISC software stores timestamps in GMT rather than in the 
local timezone to avoid all sorts of nonportable painful issues with local 
timezone conversions.

Regards,
-- 
-Chuck

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

Re: Empty CNAME chain, should getaddrinfo() return EAI_NONAME or EAI_FAIL?

[Chuck Swiger]

On Apr 28, 2011, at 3:23 AM, Havard Eidnes wrote:
www.apple.com.  281 IN CNAME www.isg-apple.com.akadns.net.
 www.isg-apple.com.akadns.net. 60 IN CNAME www.apple.com.edgekey.net.
 www.apple.com.edgekey.net. 17295 IN CNAME e3191.c.akamaiedge.net.
 ...
 
 As a matter of terminology, in the quoted example, I see a chain
 of three CNAME records.  That's not what I would call an empty
 CNAME chain.
 
 What I do see, though, is a CNAME chain of three CNAME records,
 but where the ultimate target of the CNAME chain exists, but does
 not have any data of the requested type.  Therefore, in the DNS
 you get a NOERROR status code, and an answer section which does
 not contain any records of the requested type.

Agreed.  Akamai's EdgeSuite doesn't provide IPv6  records at this time, but 
e3191.c.akamaiedge.net does have an A record.

 should getaddrinfo() return EAI_NONAME or EAI_FAIL?
 
 RFC 3493 says:
 
   [EAI_NONAME]The name does not resolve for the supplied
   parameters.  Neither nodename nor servname were
   supplied.  At least one of these must be supplied.
 
   [EAI_FAIL]  A non-recoverable error occurred when attempting to
   resolve the name.
 
 Which means that it should probably return EAI_NONAME; it's the least
 bad error code among the ones listed in RFC 3493 for getaddrinfo(),
 although one should not be mislead to think that this means that the
 DNS said NXDOMAIN.

+1 to this analysis as well.

Regards,
-- 
-Chuck

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

Re: Empty CNAME chain, should getaddrinfo() return EAI_NONAME or EAI_FAIL?

[Chuck Swiger]

On Apr 28, 2011, at 11:52 AM, Doug Barton wrote:
 Agreed.  Akamai's EdgeSuite doesn't provide IPv6  records at this time, 
 but e3191.c.akamaiedge.net does have an A record.
 
 I understand what you're saying, but I've always referred to such a thing as 
 an empty CNAME chain because it doesn't result in an address record at the 
 end.  Is there a more proper term for it?

RFC-1034 talks about CNAME chains: 

Of course, by the robustness principle, domain software should not fail when 
presented with CNAME
chains or loops; CNAME chains should be followed and CNAME loops signalled as 
an error.

...and the recursive query algorithm:

If recursive service is requested and available, the recursive response
to a query will be one of the following:

   - The answer to the query, possibly preface by one or more CNAME
 RRs that specify aliases encountered on the way to an answer.

   - A name error indicating that the name does not exist.  This
 may include CNAME RRs that indicate that the original query
 name was an alias for a name which does not exist.

   - A temporary error indication.

This phrase name does not exist appears to best be represented as EAI_NONAME.

 should getaddrinfo() return EAI_NONAME or EAI_FAIL?
 
 RFC 3493 says:
 
   [EAI_NONAME]The name does not resolve for the supplied
   parameters.  Neither nodename nor servname were
   supplied.  At least one of these must be supplied.
 
   [EAI_FAIL]  A non-recoverable error occurred when attempting to
   resolve the name.
 
 Which means that it should probably return EAI_NONAME; it's the least
 bad error code among the ones listed in RFC 3493 for getaddrinfo(),
 although one should not be mislead to think that this means that the
 DNS said NXDOMAIN.
 
 +1 to this analysis as well.
 
 The original question that started me down the rabbit hole was, What error 
 code should 'ping6 www.apple.com' return?

Well, it appears that some other folks expect EAI_NONAME:

  http://www.freebsd.org/cgi/query-pr.cgi?pr=156684

...and the MacOSX version of ping6 uses it for this case:

% ping6 www.apple.com
ping6: getaddrinfo -- nodename nor servname provided, or not known

 What confuses me here is that the node does actually exist in the sense 
 that there is _an_ address record for it. So attempting to look at this from 
 the standpoint of a user, the error message I get back (in our case, 
 hostname or servname not provided, or not known) doesn't make any sense. 
 (Although admittedly the does not resolve for the supplied parameters part 
 of the definition does seem to.) Since for the purpose of ping6 no  
 record at the end of the chain is a non-recoverable error, _FAIL 
 (non-recoverable failure in name resolution) seems to make more sense.

If the nameserver returned a failure (ie, NXDOMAIN, SERVFAIL), then I would 
agree with EAI_FAIL.

However, it didn't fail; you just asked a question which it answered 
successfully by providing all of the data which matched the query type; ie, the 
CNAMES up to the end of the chain, but not including the A record which 
terminates it, since you asked for an  instead.

 Is it possible that what we need is a new error code to designate something 
 exists here, just not what you asked for? If _NONAME is intended to indicate 
 that it seems overloaded. Alternatively I think we need to improve the 
 language of our error messages. :-/

As Harvard mentioned, EAI_NODATA?  :-)

Regards,
-- 
-Chuck

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

Re: BIND9 fails resolving after connecting to VPN

[Chuck Swiger]

Hi--

On Apr 8, 2011, at 10:27 AM, kapetr wrote:
 After connect to them (new network device created - tun or tap and
 default route changes) my BIND is not able to reach other (root)
 nameservers. And resolve requests fails.

This is due to how you are operating your VPN.  Change it to only add a route 
for the subnet of the remote end rather than making it change your default 
route:

  
http://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static-key-mini-howto.html

Regards,
-- 
-Chuck

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

Re: BIND9 fails resolving after connecting to VPN

[Chuck Swiger]

On Apr 8, 2011, at 1:07 PM, kapetr wrote:
 I absolutely do not understand your answer.

OK.

 I use the VPT to anonymisation. I need all traffic to go over the VPN.

OK.  That's not the usual method of operation for a routed VPN, but is more 
commonly used when doing bridging.

 The VPN must be used as target - default route. It is standard in
 usage of such services, it is what I need and want.

It's not standard behavior, but if it is what you want, very well.

 I thing in fact, that the problem with BIND has nothing common with
 things around VPN. BIND simple get crazy when new net device is
 added and/or routes are changed.
 
 All apps use this new  route, why BIND not ?!

The kernel routing table (disciplined by static routing entries, or routed, 
BGP, OSPF, etc) and possibly firewall forwarding rules determine where network 
traffic is sent.

There's nothing which would cause BIND to behave any differently than any other 
userland app which is not tweaking the routing table.  This implies that there 
may be firewall rules in place between you and the VPN endpoint which are 
breaking DNS and/or EDNS0 aka RFC-2671.

What does:

  dig +short rs.dns-oarc.net txt

...do when your VPN tunnel is up?

Regards,
-- 
-Chuck

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

Re: BIND9 fails resolving after connecting to VPN

[Chuck Swiger]

On Apr 8, 2011, at 2:23 PM, kapetr wrote:
 What does:
 
 dig +short rs.dns-oarc.net txt
 
 ...do when your VPN tunnel is up?
 
 After VPN up and restart of BIND:
 
 hugo@duron650:~$ dig +short rs.dns-oarc.net txt
 ;; connection timed out; no servers could be reached
 hugo@duron650:~$ 

Hmm.  Your local nameservers probably are listed in /etc/resolv.conf, otherwise 
consider adding @localhost or whatever is needed to talk to them.  Something is 
blocking DNS traffic going via your tunnel, presumably.

tcpdump and traceroute might help diagnose.  Or try switching to hitting 
4.2.2.2 or some other well-known public nameserver via dig, and see whether you 
can get a response from them.

Regards,
-- 
-Chuck

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

Re: Best ipfw Rules for DNS-SEC

[Chuck Swiger]

On Mar 15, 2011, at 11:08 AM, Martin McCormick wrote:
 Is there a recommended set of firewall rules that insure that all
 necessary DNS traffic can enter and leave, even the larger
 packets that result from dns-sec?


# allow UDP DNS queries out to the world, and in to your nameservers
## It's faster to do this stateless, and reduces DoS risk against the firewall,
## but you are exposing your network to UDP port scans from source port 53
## (if you have other open UDP ports).  If you want to be stateful, switch to:
##   add pass udp from any to $NAMESERVER_IP 53 keep-state
##   add pass udp from $YOURNET to any 53 keep-state

add pass udp from any to $NAMESERVER_IP 53
add pass udp from $NAMESERVER_IP 53 to any
add pass udp from $YOURNET 53,1024-65535 to any 53
add pass udp from any 53 to $YOURNET 53,1024-65535

# allow TCP DNS outbound and inbound only to nameserver boxes
## Likewise, you can add keep-state if you want to be stateful;
## in which case the established line can be removed.
add pass tcp from any to any established
add pass tcp from $YOURNET to any 53 setup
add pass tcp from any to $NAMESERVER_IP 53 setup

--

For something like a Cisco PIX/ASA, you probably want no fixup protocol dns 
to avoid breaking EDNS, but fixup protocol dns maximum-length 4096 might be a 
workable alternative.

Regards,
-- 
-Chuck

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

Re: Some hosts not resolving from No-IP by our DNS servers

[Chuck Swiger]

Hi--

On Mar 9, 2011, at 10:25 AM, Frank Pikelner wrote:
 I'm having a problem resolving several hosts from NO-IP. When I attempt to 
 resolve them from our DNS servers I get no reply (we can resolve other 
 hosts). I'm not certain why the resolution stops. If I force a resolution 
 using external DNS servers using dig (i.e. Google 8.8.8.8) the hosts resolve 
 without problem. Here is the trace from our DNS server:
 
 dig oa.in-ip.info +trace

I see NXDOMAIN for oa.in-ip.info here, and whois doesn't seem to believe that 
in-ip.info exists

Regards,
-- 
-Chuck

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

Re: BIND9 SERVFAIL on some .gov addresses

[Chuck Swiger]

On Feb 10, 2011, at 11:26 AM, Ryan Novosielski wrote:
 dig: isc_socket_create: address family not supported
 
 I've read that I shouldn't let this error message lead me anywhere in
 particular. Does anyone have some advice for where to start
 troubleshooting?

The error message you mention is likely an attempt to do something with IPv6 
addresses; perhaps your machine or your network is explicitly configured to do 
IPv4 only?  Does a dig against a well-known working nameserver return valid 
results like below?

% dig -t mx health.nyc.gov @4.2.2.2

;  DiG 9.6.3  -t mx health.nyc.gov @4.2.2.2
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 12326
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;health.nyc.gov.IN  MX

;; ANSWER SECTION:
health.nyc.gov. 900 IN  MX  10 vwall4.nyc.gov.
health.nyc.gov. 900 IN  MX  10 vwall1.nyc.gov.
health.nyc.gov. 900 IN  MX  10 vwall2.nyc.gov.
health.nyc.gov. 900 IN  MX  10 vwall3.nyc.gov.

;; Query time: 29 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Thu Feb 10 14:42:15 2011
;; MSG SIZE  rcvd: 124

Regards,
-- 
-Chuck

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

Re: BIND9 SERVFAIL on some .gov addresses

[Chuck Swiger]

On Feb 10, 2011, at 12:39 PM, Ryan Novosielski wrote:
 health.nyc.gov query-errors:
 
 10-Feb-2011 15:32:30.682 query-errors: debug 1: client
 130.219.34.129#55935: query failed (SERVFAIL) for health.nyc.gov/IN/MX
 at query.c:4630
 10-Feb-2011 15:32:30.682 query-errors: debug 2: fetch completed at
 resolver.c:3057 for health.nyc.gov/MX in 0.46: failure/success
 [domain:nyc.GOV,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:4,findfail:0,valfail:0

The adberr count looks like it can only be incremented by two code sections in 
lib/dns/resolver.c:

if (result != ISC_R_SUCCESS) {
if (result == DNS_R_ALIAS) {
/*
 * XXXRTH  Follow the CNAME/DNAME chain?
 */
dns_adb_destroyfind(find);
fctx-adberr++;
}
}

[ ...and... ]

if ((find-options  DNS_ADBFIND_LAMEPRUNED) != 0)
fctx-lamecount++; /* cached lame server */
else
fctx-adberr++; /* unreachable server, etc. */

This implies a connectivity issue between your client and the nyc.gov 
nameservers, I think.
But there are local wizards lurking who are much more familiar with the code 
than I

For the other example:

  resolver.c:3178 for idphdomain.idph.state.ia.us/MX in 30.69: timed
 out/success [domain:idphdomain.
 idph.state.ia.us,referral:3,restart:4,qrysent:20,timeout:19,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]


I get no response either.  I'd imagine a delegation problem somewhere in the 
list of domains, although if you poke around, you can find servers which will 
answer and claim no MX records exist:

% dig -t ns idphdomain.idph.state.ia.us @dns1.uiowa.edu

;  DiG 9.6.3  -t ns idphdomain.idph.state.ia.us @dns1.uiowa.edu
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 38483
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;idphdomain.idph.state.ia.us.   IN  NS

;; AUTHORITY SECTION:
idph.state.ia.us.   28800   IN  NS  cyclone.idph.state.ia.us.
idph.state.ia.us.   28800   IN  NS  hawkeye.idph.state.ia.us.
idph.state.ia.us.   28800   IN  NS  panther.idph.state.ia.us.
[ ... ]

% dig -t mx idphdomain.idph.state.ia.us @cyclone.idph.state.ia.us

;  DiG 9.6.3  -t mx idphdomain.idph.state.ia.us 
@cyclone.idph.state.ia.us
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 58256
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;idphdomain.idph.state.ia.us.   IN  MX

;; AUTHORITY SECTION:
idphdomain.idph.state.ia.us. 86400 IN   NS  
idphadc4.idphdomain.idph.state.ia.us.
idphdomain.idph.state.ia.us. 86400 IN   NS  
w2k8dc1.idphdomain.idph.state.ia.us.
idphdomain.idph.state.ia.us. 86400 IN   NS  
w2k8dc2.idphdomain.idph.state.ia.us.
idphdomain.idph.state.ia.us. 86400 IN   NS  
idphadc1.idphdomain.idph.state.ia.us.
idphdomain.idph.state.ia.us. 86400 IN   NS  
idphadc2.idphdomain.idph.state.ia.us.
idphdomain.idph.state.ia.us. 86400 IN   NS  
idphadc3.idphdomain.idph.state.ia.us.
[ ... ]

Regards,
-- 
-Chuck

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

Re: bind Bind or BIND?

[Chuck Swiger]

On Jan 26, 2011, at 6:02 PM, p...@mail.nsbeta.info wrote:
 When talk to others, I never describe it clearly for naming bind.
 is it bind or Bind or BIND? is bind an abbreviation word? 

Yes, BIND is an acronym for Berkeley Internet Name Daemon.

Regards,
-- 
-Chuck

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

Re: named: high memory usage under FreeBSD-7...?

[Chuck Swiger]

Hi, Dough--

On Dec 21, 2010, at 2:22 PM, Doug Barton wrote:
 On 12/16/2010 14:48, Chuck Swiger wrote:
 Hi, bind-users--
 
 I'd recently updated a machine to FreeBSD 7-STABLE, and I've noticed
 that named from the base system (which claims to be BIND 9.4-ESV-R4)
 is using more than twice as much memory as it used to:
 
 Hey Chuck, sorry I didn't respond to this on the FreeBSD list. In FreeBSD 6.x 
 we had BIND 9.3.x. BIND 9.4.x definitely uses more memory, this is a feature. 
 :)

As I mentioned in another thread, the issue was that it appears max-cache-size 
option wasn't being honored by base named (claims to be BIND 9.4.-ESV-R4) from:

FreeBSD example.com 7.4-PRERELEASE FreeBSD 7.4-PRERELEASE #1: Tue Dec 14 
19:55:55 EST 2010

...whereas top showed that named from dns/bind-9.6 filled its cache under load 
until it reached the max-cache-size plus a chunk for the recursive clients, and 
then remained at a stable size afterwards.

 PID USERNAMETHR PRI NICE   SIZERES STATETIME   WCPU  COMMAND
 706 bind  4   40 69424K 57292K kqread   0:09  0.00%  named
 
 It's serving about 20 zones with total record size of less than 100K,
 and has the following option block set:
 
 options { directory /var/named; recursive-clients 400;
 clients-per-query 210; max-clients-per-query 220; max-cache-size
 10m; };
 
 This box was previously running FreeBSD-6.4 and dns/bind94 port,
 
 Doubtful, as the code for BIND 9.4 in the base in FreeBSD 7.x is identical to 
 that in the port. It's possible of course, but I can't see any reason off 
 hand that the same BIND code running on FreeBSD 6 would use twice as much 
 memory on 7.

I can't see any reason why the named from 7.x base would ignore 
max-cache-size-- unless it was picking up some other named.conf entirely, but 
then it wouldn't be loading the zones it was told to look at-- but the behavior 
was (and still is, AFAIK) reproducible.

 and named never crept above 30M VSIZE/RES even under heavy load (ie,
 adnslogres -c 100 against a million line httpd-access.log file);
 the size above is from named running for about a day, *without*
 putting any significant load upon the nameserver
 
 That must have been a very high percentage of the same hostnames showing up 
 in those million lines if all of them fit into a 10 meg cache.


They *don't* all fit into a 10 meg cache.  That's why it is useful for testing 
whether the named process is growing too big.

With dns/bind-9.6 port (ie ...ESV-R3), if I changed max-cache-size from 10 to 
20 to 50 MB, then the process size grew to about 3 MB + 2 MB per 100 recursive 
clients being used + an amount that would grow to what max-cache-size is set at 
when put under load.

If max-cache-size = 10 MB and I run adnslogres with -c 100, then BIND 
9.4-ESV-R4 would slowly grow to ~60MB RSIZE whereas BIND 9.6-ESV-R3 would grow 
to about 15 MB RSIZE and then stay there.  If max-cache-size = 20 MB and I run 
adnslogres with -c 200, then BIND 9.4-ESV-R4 would grow to ~60MB RSIZE whereas 
BIND 9.6-ESV-R3 would grow to about 27 MB RSIZE.   (etc)

Regards,
-- 
-Chuck

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

Re: named: high memory usage under FreeBSD-7...?

[Chuck Swiger]

On Dec 21, 2010, at 4:34 PM, Doug Barton wrote:
 You're combining too many variables. Whilst on the same platform (presumably 
 FreeBSD 7) install dns/bind94, run your tests. Then deinstall that, and 
 install dns/bind96; then run your tests.
 
 I suspect that what you're seeing is actually a problem in BIND 9.4, 
 irrespective of platform. The method described above is the way to verify 
 this.

OK-- I'll see what I can do.

-- 
-Chuck

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

named: high memory usage under FreeBSD-7...?

[Chuck Swiger]

Hi, bind-users--

I'd recently updated a machine to FreeBSD 7-STABLE, and I've noticed that named 
from the base system (which claims to be BIND 9.4-ESV-R4) is using more than 
twice as much memory as it used to:

 PID USERNAME   THR PRI NICE   SIZERES STATETIME   WCPU COMMAND
 706 bind 4   40 69424K 57292K kqread   0:09  0.00% named

It's serving about 20 zones with total record size of less than 100K, and has 
the following option block set:

options {
   directory /var/named;
   recursive-clients 400;
   clients-per-query 210;
   max-clients-per-query 220;
   max-cache-size 10m;
};

This box was previously running FreeBSD-6.4 and dns/bind94 port, and named 
never crept above 30M VSIZE/RES even under heavy load (ie, adnslogres -c 100 
against a million line httpd-access.log file); the size above is from named 
running for about a day, *without* putting any significant load upon the 
nameserver

Regards,
-- 
-Chuck

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