Re: Forward zone not working

2016-05-20 Thread John Wobus
On May 16, 2016, at 5:35 PM, MegaBrutal  wrote:
> 
> 2016-05-16 19:45 GMT+02:00 Alan Clegg :
>> On 5/16/16, 1:30 PM, "MegaBrutal" > behalf of megabru...@gmail.com> wrote:
>> 
>>> I want to have valid reverse & forward hostnames set up
>>> for this /64 subnet.
>> 
>> This is silly.  Don't do this.
> 
> Why?
> 
> Most ISPs set up reverse & forward domain names for pool addresses.
> OK, I'm not an ISP, but it really seems to be a widely accepted and
> endorsed policy, to the point that addresses not having a reverse DNS
> often treated as suspicious.

I’ve expected IPV6 would drive away the demand for PTR records for personal 
devices.
I’ve been generating PTR records for decades, beginning when servers began
using PTR-existence as a sign of legitimacy.  This includes providing
reverse pointers for every address in a dynamic pool.

I've figured “demanding PTRs” would go away with IPV6 since SLAC (and sheer 
size)
makes the idea of providing them less than feasible.  Since security-conscious
apps and library routines will need other changes to handle IPV6, it’ll be 
natural
to eliminate something that would be both difficult and useless.  I figure the
number of clients without PTR records will tip a balance and servers will
no longer be able to afford to demand them.

Auto-generated individual PTR records for large pools are a whole lot like no 
pointer
records at all, and seem to me like busy work.  Though perhaps an unvaried PTR 
that
shows “this address is in a pool, and not a static address” would offer useful 
info,
perhaps with a DNS wildcard entry (if you line up your pool with a CIDR block)? 
 For
individual devices that are offering to accept connections, dynamic DNS could be
useful: if someone connects to you and is willing to receive connections, an 
individual
PTR record let you could find out their name first.

These comments don’t apply to PTR records for individual servers.

John Wobus
Cornell University IT

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

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

Re: Bind response to query's very small edns udp payload size

2016-04-15 Thread John Wobus

>> What does bind try to do if the client specifies a udp size of less than 512?
> 
> From RFC 6891:
> 
> Values lower than 512 MUST be treated as equal to 512.

Doh.

The behavior I saw was a shorter authority section and no additional section 
(or TO)
when I specified a UDP buffer of 200 as opposed to sending a non-EDNS request.
But I do see that an EDS request with UDP buffer size 512 gives me
exactly the same result as with buffer size 200.  I speculate
bind will skip part of its usual authority section and provide no
TC bit as long as it can give the full answer section.

The actual issue I was investigating is indeed unrelated.  I was merely
eliminating possibilities.

John Wobus
Cornell IT

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

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


Bind response to query's very small edns udp payload size

2016-04-12 Thread John Wobus
What does bind try to do if the client specifies a udp size of less than 512?
I’ve been trying queries and here is what I’ve seen:

I have a query that ordinarily receives a response with an answer section
and an authority section, the response length being ~ 500.

If I specify a udp size of 200, then I receive the same answer section,
but minus the authority section.  But the received length is greater than 200,
and the tc flag is not set.

(In contrast to this, if I try a different query that gets a truly long answer,
specifying a udp size of 512, then I do get a response with the
tc flag set and with no answer-section lines.)

I’ve been looking at a customer's reported problem,
testing scenarios and behavior that might explain it, so this is a bit
of an academic question just to know what to expect from bind.
The actual problem is likely (in my mind) to be a firewall or
client configuration.

FYI:
$ ./named -v
BIND 9.9.8-P4 (Extended Support Version) 

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

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

Re: Can bind be configured to not drop RR's from the cache when the upstream DNS server is unresponsive

2016-03-25 Thread John Wobus
On Mar 18, 2016, at 6:28 AM, Barry Margolin  wrote:
> In article ,
> Mark Andrews  wrote:
> 
>> How do you actually expect this to ever work in real life?
> 
> I'm pretty sure Google DNS does this. Other resolver operators often get 
> complaints about "Why can't I look up  through your DNS 
> servers when I can do it through Google DNS?"

I’d guessed Google just re-queries before it needs to, which has benefits but
requires a more complex “clean out very-seldom-used records” strategy.
I’d imagine they'd use a somewhat-random amount of time to pre-query
as one of their measures against cache poisoning.

This would be a good nameserver feature, e.g. when a response is given
from the cache, a secret (shorter) ttl is adjusted to help assure continuity.
Or other variants.  Such a feature might address Ron’s concern.
(I believe I recall discussions on this or another list, perhaps even
a feature in the wings.)

In any case, I cringe at the thought of overriding TTLs.  They’re there
for a reason.  In some instances, overriding could “help”, but in others, it
would be really, really bad.

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

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

Re: Configuring different TTLs in multiple RRs for the same domain name, TYPE, and CLASS

2016-03-25 Thread John Wobus
> IMHO, memory is so cheap these days that any server that has to eject 
> cache entries because of memory limits means the server operator isn't 
> really trying to do their job well.

For handling host names, perhaps yes.

But it implies sanity on the part of all apps that your clients use.
App developers can use DNS as a database for any data, and in insanely large 
amounts.
Examples of things like this have been spam databases, and I vaguely recall
some social network doing something.  A single app could easily
push the DNS much harder, the only capacity limit being the tension between
how much memory DNS operators provide and client demands to support this
otherwise-wonderful app.

John Wobus
Cornell IT

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

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


Re: Configuring different TTLs in multiple RRs for the same domain name, TYPE, and CLASS

2016-03-25 Thread John Wobus
On Mar 24, 2016, at 12:18 PM, Ben Bridges  wrote:
> 
> TXT records are multiple-purpose.  They can be used for SPF records, Office 
> 365 “MS” records, DMARC records, or whatever arbitrary uses someone dreams 
> up, all for the same domain name.  Microsoft wants a short TTL for their 
> Office 365 records, but I would prefer to generally use a longer TTL for most 
> records (including other TXT records) in order to reduce the query load on 
> our servers.  It would be nice to be able to set a short TTL for the Office 
> 365 record but a longer TTL for other TXT records for the same domain name.
>  
> Thanks,
> Ben

From the caching server's point of view: if among two records, it expires just 
one of them, keeping the other one, then when another query comes:

Strategy 1: The caching server just returns the record it has?
Strategy 2: The caching server re-queries the auth server?

Strategy 1 implies this next query doesn’t get all the data, perhaps not the 
data the client needs.
Strategy 2 acts exactly the same as if all the records expired at once.  Except 
you also have this
new weird status to remember, with no benefit.

Knowing when a query to the auth server is necessary for the client’s usage 
would require magic knowledge, i.e. which of the two records record the client 
is looking for.  The RFCs take this into account and require the TTLs to be the 
same.

John Wobus
Cornell IT

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

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

Re: hhs.gov resolvers broken, or BIND misconfigured?

2016-03-04 Thread John Wobus
> Our recursive resolver periodically returns SERVFAIL for lookups for
> hhs.gov records, which are served by these nameservers:
> 
> rh202ns1.355.dhhs.gov.  168 IN  A   158.74.30.98
> rh202ns1.355.dhhs.gov.  14260   IN  2607:f220:0:1::2a
> rh202ns2.355.dhhs.gov.  168 IN  A   158.74.30.99
> rh202ns2.355.dhhs.gov.  14260   IN  2607:f220:0:1::2b
> rh120ns2.368.dhhs.gov.  81  IN  A   158.74.30.103
> rh120ns2.368.dhhs.gov.  81  IN  2607:f220:0:1::2d
> rh120ns1.368.dhhs.gov.  168 IN  A   158.74.30.102
> rh120ns1.368.dhhs.gov.  14260   IN  2607:f220:0:1::2c

I don’t know the cause, but checking these nameserver authoritative
and glue records, I see ttl 300 for the authoritative records and ttl 86400
for the gov glue records.  The caching ttls above suggest the  records are
cached glue and the A records are cached authoritative.  Just an observation.
But that seems like something bind would deal with every day, even with both A
and  records for the same NS name.  One clear thing about the above
query is that renewals from the authoritative the nameservers don’t happen to
be in synch.

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

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

Re: DNS Server goofiness

2016-02-05 Thread John Wobus
I agree that it could be the NAT firewall: some firewalls have features to
network-address-translate the answer portion of DNS responses.
Or with bind “views" (or “RRL") you could deliberately make it give
differing answers, but you’d know.

The firewall documentation might help.
Or you can test whether it’s the firewall by doing a norecursion dig from 
outside the
firewall from a known IP while doing a tcpdump on port 53
to/from the client IP on the server.  Then you can prove bind is producing what
you expect.  But if the FW is set to address-translate in both directions,
its more of a challenge to focus such a packet capture.  If the server also has
a FW configuration including NAT, that could be doing it as well.

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

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

Re: Extracting stats from BIND XML stats file : issues

2016-01-15 Thread John Wobus
I haven’t used the XML stats so I have no direct experience.
Your formula looks right to me.

If it were me, I’d confirm the load traffic as much as I could,
e.g. os udp counts, tcpdumps at both ends, etc.  I’d
want to make sure it was bind that was doing something strange.

It occurred to me that a bind rrl configuration could affect
this, but a little thought told me that was unlikely to be the
issue.

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

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

Re: Bind9 on VMWare

2016-01-15 Thread John Wobus
Re vmware, I’m definitely interested in anything folks
have discovered about udp performance issues but I have
no negative experience to offer.  We mix vmware and hardware,
but have both auth and query servers on both.  Load tests
didn’t reveal any issues that made us reconsider.

We had an interesting time when we migrated a DNS server that
doubled as our central ntp server into vmware.
Later we moved the ntp server back to bare metal somewhere.
But the issue was not udp; it was the virtualized “hardware” clock.

I have a personal concern about dependencies, e.g. if you ever have
to deal with a problem that’s taken a whole vmware cluster
down.  If the infrastructure or the folks attempting
to fix the infrastructure depend on dns,
or even if they merely work more efficiently when dns is there,
then having that huge single point of failure that takes down
dns could have costs.  Same for a lot of low-level services.
Overall architectures can take this into account.

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

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

Re: rndc flushname not working

2015-04-10 Thread John Wobus

In this particular case, when the issue came to me, the
name servers for the domain were able to return the result with no
problems, other caching servers throughout the company had no issues,
but this group of servers that apparently had tests run against the
domain prior to it being fully setup could not resolve it and nothing
short of a full flush of the cache would fix the issue.  That leads me
to believe there is some data that gets held in cache not cleared by a
flushname that is relevant but not documented.


It could be a nameserver in the delegation chain cached
wrongly.  If that nameserver isn't in the domain to which
flushtree was directed, another flush aimed at that nameserver's name
would be needed.  I recall the "fun" of hunting down some of those.
CNAMEs can also create fun.

John Wobus
Cornell University IT

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

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


Re: Too many connections on the same IP

2015-03-06 Thread John Wobus

Re firewalls: I've been forced to adjust firewall rules
to be stateless to get busy DNS servers to work.
If the state table is filling, that's easy to check.
Stateless rules have traps for the unwary so assure
yourself that you understand all the issues.
Specifically, make sure return traffic isn't triggering
state.

Over the years as typical memory in a server grows,
systems' default tuning parameters have increased
and often things do just work without such adjustments.

Another tuning issue for bind is assuring it is configured
to handle sufficient recursive queries for your load.
This is also easy to check so should be one of the
first things checked.

Given that you say only one of your servers' IP
addresses has the issue, all this seems
moot.  Viewing the connections with netstat seems
useful.  Or if there is another system on
the same IP, it is crucial to fix that.  Such a
problem could just kill communications but it could
also cause symptoms that only show under load.

Another thought is a firewall in front of your server.
And speaking of firewalls, some have a feature to
govern the level of load they allow into of a part.

John Wobus
Cornell University IT


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

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


Re: Bind's handling of lame nameservers

2014-12-16 Thread John Wobus

On Dec 16, 2014, at 4:26 PM, Mark Andrews wrote:

We tried to check aa for just this reason but there are to many
broken authoritative servers which just don't set "aa=1" on all the
servers for the zone that we had to back the code change out.

I would just use a server clause to mark nameserver as bogus.


Thanks.  I did have a vague recollection that an earlier posting
said that.

John
"You can't win.  You can't break even.  You can't quit the game."
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Bind's handling of lame nameservers

2014-12-16 Thread John Wobus

How do BIND caching servers handle received responses with
no aa flag?  We're running BIND 9.9.6-P1 and I received a
report of a query that our server sometimes answered as
expected and sometimes didn't.
The offending name is not one we are authoritative for.
I checked the offending name and found that just one of
its nameservers answered badly: with an empty answer section,
a "NOERROR" status and no "aa" flag set.

I know to contact the other site and report this, but
I'm wondering what bind tries to do.  Assuming the above was
the situation when the reported symptoms occurred, I would
have guessed bind would act on the lack of an "aa" flag
and either answer the original query with SERVFAIL or
immediately retry with a different server,
and issues to the end user would be pretty rare.

FYI, the query was for MX records for convergepay.com
and their nameserver atl-embr-mdf1-lbtrans-7000-dl.elavon.net
was listed among the authoritative NS records but
answered an MX query as described.  I tested both with
and without requesting recursion.  In fact, every name
and record type I asked it got a response of
"NOERROR", no answer section, and no "aa" flag.

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

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


Re: Digging to the final IP

2014-10-24 Thread John Wobus

On Oct 21, 2014, at 4:00 PM, Evan Hunt wrote:

On Tue, Oct 21, 2014 at 12:07:15PM -0700, Warren Kumari wrote:

dig A $name | awk '$0 ~ /status/ && $0 !~ /status: NOERROR,/ {
   sub(",", "", $6 ); print $6; x=1
  }
  $4 == "A" { print $5; x=1 }
  END { if (!x) print "TIMEOUT" }'



Because, not everyone is as stunningly brilliant as you?

To a non-zero population of this list the above looks like line- 
noise...


Could be worse, could be perl...


But if perl were acceptable,

perl -e 'printf "%vd\n", (gethostbyname "example.com")[4]'

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

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


Re: slave zone files unreadable

2014-07-11 Thread John Wobus

In cases analogous to this, software often saves both
text and binary, and when initializing, uses mtime to
decide whether it can safely use the binary.  Some resources
are spent storing the extra file and admins have yet
another way to screw things up, but the strategy
does have benefits.

John Wobus
Cornell University IT

On Jul 9, 2014, at 11:31 AM, Evan Hunt wrote:


On Wed, Jul 09, 2014 at 03:16:04PM +0200, Reindl Harald wrote:

however, i wonder what takes 90 seconds to load 5000 zones


It scales with both the number of zones and the number of records per
zone.  Some of those zones are probably quite large.

When you're reading text, it takes time to do the lexical analysis and
parsing.  When reading text *or* raw, it takes time to examine each  
node in
the zone file, determine its name, walk down through the nodes of a  
growing

red-black tree, allocate memory, and add the data.

A map file is a memory image of a fully-formed red-black tree; it can
be zapped into memory in one go, then we walk through the tree  
validating

checksums and updating the pointers, which is obviously much quicker.

(In fact it could be almost instant if we did the checksums-and- 
pointers
bit lazily, as the data was accessed rather than immediately at load  
time.
That introduces a lot of complexity, though; if a zone file is  
corrupt,

BIND expects to discover the fact right away, not at some random time
later on.)

--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to  
unsubscribe from this list


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


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

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


Re: Multi-master (HA)

2014-05-09 Thread John Wobus

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

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


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

and not force the operator to deal with zone files that suddenly need to
switch between binary and ascii.  (There may be good ways to do this now
that I'm unaware of.) (I've wondered why bind doesn't simply write an
ascii copy of the zone file in addition to the binary copy.)

Running multiple dynamic-dns masters would be absolutely fantastic  
except

of course when it didn't work.  Seems like a reason to have multiple
masters is to handle the case where some are unreachable, in
which case keeping them in synch becomes interesting.  If the main
point is to eliminate single points of failure, a "three masters
with quorum" system might serve the purpose.

I like the idea of configuring zone information in a zone, and think
it would be fun to be on the team brainstorming how to guard against
sneaky config attacks.

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

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


Re: Clients Matching Multiple Views

2014-04-11 Thread John Wobus

On Apr 9, 2014, at 4:14 AM, Steven Carr wrote:

However, assuming you are using views on the same IP address and not
splitting it across internal/external servers as that would screw up
NS records), you can reuse the same zone file so those zones that
appear in both internal and external views refer back to the same zone
file, then when you update that zone file both views are updated.


My understanding has been that two views that are masters for
a zone can safely share a zone file if the zone isn't dynamic (e.g.
dnsupdate, dnssec auto signing, etc), but that two views of
a slave zone shouldn't do that: you could have two
different views independently rewriting the same file, a bad thing even
if the files are known to be identical.  Furthermore, allowing that  
could

conceivably show no problems very much of the time, masking the actual
risk.

If I'm wrong, that would be a good thing to know.

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

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


NS record TTL versus nameserver's A record TTL

2013-10-08 Thread John Wobus

We received a report that a domain we serve
was not resolving at a remote site.  The site
also reported their own analysis that the issue
appeared to be that the domain's NS record had
a longer TTL than its target nameserver's
A record and their caching server didn't
seem able to handle this.  FYI, the nameserver
was not within the domain with the issue.

They took responsibility for their
nameserver's deficiency, but it
makes me wonder:
-Is this addressed by a standard?  E.g.,
 the nameserver's A record have the same
 TTL as NS records pointing at it.
-Is this addressed by a "best practice"?
-If neither of the above, is there
 a "hidden practice that knowing folk
 often follow to dodge remote
 nameserver deficiencies"?

FYI, I only received the report fourth hand
and can't tell you the nameserver software
that had this issue.

John Wobus
Cornell University IT

P.S. This made me wonder what record bind
puts in the additional section if it has
both a glue A record for a nameserver
in the zone's file and an authoritative A
record for the nameserver in the nameserver's
own zone file.  I find by TTL finagling that
it serves the authoritative A record.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: Internernal view is answering to external ping

2013-08-02 Thread John Wobus

Many use ping to check DNS issues but doing so brings in
another factor: the client's os/resolver/caching.
The 'dig' utility aims to work around this.  If 'dig'
(to the DNS server's numeric address) and 'ping' DNS resolutions
differ, you have good evidence it is a client issue.
On the other hand if both give the same unwanted answer,
you have evidence it is a server configuration issue.

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

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


Re: Reverse address entries

2013-07-05 Thread John Wobus

On Jun 28, 2013, at 3:54 PM, Ward, Mike S wrote:
I want to thank everyone for their input. It sounds like they do  
need the reverse address entries in specific circumstances so I’m  
going to recommend that they add them.


Lack of reverse records made a big difference in the distant past.
Now, I suspect the percentage of situations is much reduced,
but of course the sheer number of users/uses of the Internet is
higher.

I have a suspicion that the deployment of IPV6 will kill off
using reverse lookups for "validation".  Of course DNS supports
IPV6 reverse records, but IPV6 poses challenges for some
DNS strategies, e.g. setting up static "placeholder" DNS records
for each address in a dynamically-addressed subnet.

John
Cornell University IT


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

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


Re: How to suppress ADDITIONAL SECTION per zone

2013-07-05 Thread John Wobus

Other possibility is to implement packet rate limiting - a patch was
discussed here a few days/weeks ago.


I endorse this suggestion: we were faced with such attacks and were
naturally leery about issues we might run into running a patched bind
and the additional tuning it could require.  Our experience is: the RRL
patch, used with its default parameters, simply does the job.

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

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


Re: Bind unable to get MX reocrd from Parrent name server

2013-07-05 Thread John Wobus

The other DNS server software is working around or ignoring
the issues.  Server software varies in how much it ignores or
works around bad domain setups.  Also, in some situations,
configuration problems result in symptoms that come and go.

One reason DNS software is picky about correct setups is security:
ignoring some configuration issues increases the chance
of passing along bad, possibly malicious answers.  Bind is
apparently pickier than some other DNS server software.
I have to believe some public resolvers have considerable extra
logic to try to "partially validate" and use domains that
are incorrectly set up.

The ideal way to fix the issue is to get the owner of
the domain to fix it.

John
Cornell University IT

On Jul 5, 2013, at 7:59 AM, Fosiul Alam wrote:


Hi
thanks for reply,
I am not the domain admin for "rbcaa.co.za"
I can see they have issue with their domain setup .
but what I want to know is :
when all Dns server can resolved their mx record example ,
mxtoolbox,introdns,google .. (Despite they have issue with their dns
setup for that domain (as you said) ) then why we cant ??

Thanks for looking into it .

On Fri, Jul 5, 2013 at 12:45 PM, Steven Carr  wrote:

Your glue is broken. You need to update the glue NS records in the
parent to reflect the actual nameservers that are authoritative for
the zone.

It also looks like you could have some data mismatch between zones
hosted on (ns1.yithosting.co.za + ns2.yithosting.co.za) and
(demeter.is.co.za + babylon.mitsol.co.za). Check that the zone data  
is

consistent across the nameservers.

Steve

On 5 July 2013 12:35, Fosiul Alam  wrote:

Hi
Occasionally we see customer is complainning that we are not able to
resolve mx record when mxtoolbox or other website can resolve  
their mx

record .
If i do a trace on the domain, i get bellow .

now the problem is :
demeter.is.co.za. and babylon.mitsol.co.za does not know anything
about MX record of that domain. but if i query by using  parent name
server ns1.yithosting.co.za. and ns2.yithosting.co.za , it returns  
the

mx record .

but mxtoolbox, introdns can resolve the mx record although they
complain the same that


The following nameservers are listed at your nameservers as
nameservers for your domain, but are not listed at the parent
nameservers (see RFC2181 5.4.1). You need to make sure that these
nameservers are working.If they are not working ok, you may have
problems!
demeter.is.co.za
babylon.mitsol.co.za

ERROR: One or more of the nameservers listed at the parent servers  
are

not listed as NS records at your nameservers. The problem NS records
are:
ns1.yithosting.co.za
ns2.yithosting.co.za
This is listed as an ERROR because there are some cases where nasty
problems can occur (if the TTLs vary from the NS records at the root
servers and the NS records point to your own domain, for example).
""

then why our bind is unable to resolve mx record ???
Thanks for the  help


[root@za-ns-8 ~]# dig  rbcaa.co.za +trace

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> rbcaa.co.za  
+trace

;; global options: +cmd
. 447499 IN NS a.root-servers.net.
. 447499 IN NS j.root-servers.net.
. 447499 IN NS l.root-servers.net.
. 447499 IN NS d.root-servers.net.
. 447499 IN NS k.root-servers.net.
. 447499 IN NS g.root-servers.net.
. 447499 IN NS i.root-servers.net.
. 447499 IN NS h.root-servers.net.
. 447499 IN NS m.root-servers.net.
. 447499 IN NS c.root-servers.net.
. 447499 IN NS f.root-servers.net.
. 447499 IN NS e.root-servers.net.
. 447499 IN NS b.root-servers.net.
;; Received 508 bytes from 10.33.91.35#53(10.33.91.35) in 14 ms

za. 172800 IN NS za1.dnsnode.net.
za. 172800 IN NS disa.tenet.ac.za.
za. 172800 IN NS nsza.is.co.za.
za. 172800 IN NS za-ns.anycast.pch.net.
za. 172800 IN NS sns-pb.isc.org.
;; Received 360 bytes from 199.7.83.42#53(199.7.83.42) in 346 ms

co.za. 86400 IN NS ns0.plig.net.
co.za. 86400 IN NS ns.coza.net.za.
co.za. 86400 IN NS ns0.neotel.co.za.
co.za. 86400 IN NS ns1.coza.net.za.
co.za. 86400 IN NS coza1.dnsnode.net.
co.za. 86400 IN NS ns0.is.co.za.
co.za. 86400 IN NS ns4.iafrica.com.
;; Received 266 bytes from 196.4.160.27#53(196.4.160.27) in 285 ms

rbcaa.co.za. 86400 IN NS ns1.yithosting.co.za.
rbcaa.co.za. 86400 IN NS ns2.yithosting.co.za.
;; Received 108 bytes from 196.4.160.17#53(196.4.160.17) in 81 ms

rbcaa.co.za. 14400 IN A 41.203.1.156
rbcaa.co.za. 86400 IN NS demeter.is.co.za.
rbcaa.co.za. 86400 IN NS babylon.mitsol.co.za.
;; Received 99 bytes from 41.203.1.158#53(41.203.1.158) in 41 ms
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to  
unsubscribe from this list


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




--
Regards
Fosiul Alam
07877100621
http://www.fosiul.co.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to  
unsubscribe from this list


bind-users mailing list
bind

Re: Help on NXDOMAIN to try next forwarder in the list

2013-05-31 Thread John Wobus

I will add my +1:

NXDOMAIN does not mean "I don't have a number for that name but  
someone else
might." It means "The DNS lists this name as having no number (or  
whatever)."

There's no more reason to look further than if you got a positive
answer from one server and still wondered if some other DNS server
might say something else. You might just as well recheck positive
A-record answers with other servers because they might say NXDOMAIN.

The only reason to look further is if you are monitoring
for inconsistencies/brokenness.

"Settling time" is an issue, e.g. when you don't have an
effective NOTIFY authoritative servers temporarily disagree
for a significant interval.  Still, if you get two answers
(one NXDOMAIN and one A record) from servers, there is no
way to tell which is "correct", just as if you got two different
A-record answers.  It's up to the zone's maintainer to assure
the (hopefully temporary) inconsistency doesn't cause issues.

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

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


Re: Simple question about zone and CNAME

2013-04-05 Thread John Wobus

DNAME? 


Or SRV records.  Surely browsers are adding support
in the next day or two?

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

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


Re: spf ent txt records.

2013-03-22 Thread John Wobus

On Mar 18, 2013, at 12:00 AM, Mark Andrews wrote:

It's not that is is esthetically pleasing to put SPF data into its
own RR type.  It's that TXT has been hijacked and contining to add
more uses to TXT does not scale.  TXT is a reasonable record for
proof of concept.  It isn't and never has been a good long term
choice.


Absolutely.  What we should be pushing for is a spec such that if
followed, is sufficient to work, for SPF and for other users of TXT.
We should be on that track even if it is necessary to allow a lot
of time to accommodate the effort.  Ways I can see to get
back there:

1) An RFC (or RFCs) that specifies a set of specific TXT record content
formats that are specified to have particular meanings, e.g. 'don't do  
the

following unless it's an SPF record'.

2) Going even further, layer another protocol (and registry) on top
of TXT records specifying the meaning of various prefixes.

3) Transition widely-used systems that are prototyped with TXT
to an RR type specified for the purpose.

The last could even be a new TXT-like RR type invented specifically for
supporting for layering more protocols, along with a registry of  
prefixes.

I'm not enamored of that, but at least it gives the world the means to
avoid tripping over each other's feet.

It's natural that folks whose primary interest is SPF should find
all this to be busy-work of little value to themselves or
their customer base.  The benefit is for future efforts of
the SPF-sort, and it's been fortunate for the
SPF effort that TXT records were available to them without
a lot of earlier-established complicated rules of use, so they
could use TXT records to jump-start their efforts.

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

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


Re: high volume from outside our networks question

2013-02-01 Thread John Wobus

You can create 2 views "authorised" and "everyone else" which both
reference the same domain zone files so you dont need to duplicate the
zones.


On a secondary, the zone files in different views, even if identical,  
need to be

distinct.

Also, if you're allowing dynamical updating and the views need to  
serve identical
versions of the zone, then you need to arrange things so the zone is  
in just one

view.

The master of a zone with no dynamical updating could reference the  
same zone
file from multiple views but that is about the only case that it would  
work.


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

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


Re: VMware & Bind

2012-06-08 Thread John Wobus

Will bind run on VMware?


Yes, if the guest operating system supports it.


Of more interest to me is: are there limitations?
Types of configs or workloads that should
not be run under VMware?

John


P.S. Aps are sometimes distributed bundled with an OS,
i.e., forming a package that does run directly under VMware.
AFAIK ISC does not offer such a bundle for BIND.

Aps could be written to include OS function so as to
require no such bundling--I read about an ap that was
seemingly like that, but likely it was just bundled
with a Linux kernel.  AFAIK ISC does not distribute
BIND in such a form.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: allow-query for a zone

2012-01-20 Thread John Wobus

Actually, I just realized a possible counterexample: if the zone is a
subzone of another zone that the server hosts, the type of error  
depends

on the strategy used.  With the zone statement, the error will be
REFUSED; without the zone statement, it will be SERVFAIL because of  
the

lame delegation to itself.


And if it's your caching server, and the zone is delegated elsewhere,
depending upon whether the zone is configured as discussed (allow- 
query=none)
or not configured at all, you are giving your clients a REFUSED or you  
are
answering them with cached data.  One possible way to implement  
policy, e.g.

to make it less likely to reach known phishing sites.

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

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


Fwd: forwarding "@" to a different domain?

2012-01-13 Thread John Wobus
Hi All: I have a situation where I need to forward requests for  
"mydomain.com"
and "www.mydomain.com" to a third party:  
"mydomain.myshopify.com" (while still

pointing other things like MX records elsewhere).

I realize I can point a CNAME for "WWW" to "mydomain.myshopify.com",  
but how do
I point "mydomain.com" to this third party if there is no A record  
to point to?


BTW, you could say that the DNS can do its part with SRV records (on a
port-by-port basis), but that doesn't do any good since current
browsers don't look up and use such DNS records.

_http._tcp.mydomain.com. SRV 1 1 80 mydomain.myshopify.com.
_http._tcp.www.mydomain.com. SRV 1 1 80 mydomain.myshopify.com.

John Wobus

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

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


Re: variable dig results

2012-01-06 Thread John Wobus

On Jan 6, 2012, at 11:14 AM, David Forrest wrote:

On Fri, 6 Jan 2012, M. Meadows wrote:
Wondering why we get variable results from the following  
command:dig eftc.thehartford.com
(sometimes we get authority section and additional section  
feedback ... sometimes we don't)




;; Query time: 52 msec
;; SERVER: 172.25.17.185#53(172.25.17.185) ;; WHEN: Fri Jan  6  
00:10:02 2012 ;; MSG SIZE  rcvd: 202



I assume this is due to differences in response from different auth  
nameservers. If that's the case ... what does one have set up to  
return the 2nd response?


As the server wasn't specified, dig tries each of the servers listed  
in /etc/resolv.conf and used 172.25.17.185 both times, one with the  
rd flag set and got a non-authoritative answer and an  
authoritative.  I'd assume there are multiple instances or views and  
you're getting cached answers occasionally.  If consistency is  
needed, maybe specify the server with @server and/or +[no]recurse


The cited dig answers differ in that only one has the 'rd' flag  
("recursion desired"), which

suggests to me a difference in the queries.

It would be interesting to know whether +recurse versus +norecurse  
controls it. Also, +qr would

let you directly see what flags are in the query.

It's a mystery if the answers differ despite the exact same dig  
command, the same client IP and
client computer login (i.e., same .digrc if one exists).  If it's from  
different client IPs,

Bind "views" configured on the server could cause such a different.

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

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


Re: New problem with "lame-server" after Dist-Upgrade

2012-01-06 Thread John Wobus

On Dec 28, 2011, at 8:56 PM, Chris Buxton wrote:

On Dec 24, 2011, at 4:50 PM, Michelle Konzack wrote:

Dec 25 01:39:02 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'www4.l.google.com//IN':  
2001:503:231d::2:30#53
Dec 25 01:40:10 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'ns2.roka.net//IN':  
2001:500:1::803f:235#53
Dec 25 01:40:10 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'dns.roka.net//IN':  
2001:748:100:70::2#53
Dec 25 01:42:02 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'www.kaleme.com//IN':  
2001:503:a83e::2:30#53
Dec 25 01:42:02 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'pdns3.ultradns.org/A/IN':  
2001:500:2f::f#53
Dec 25 01:42:02 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'pdns4.ultradns.org/A/IN':  
2001:500:2f::f#53
Dec 25 01:42:02 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'pdns3.ultradns.org//IN':  
2001:503:c27::2:30#53
Dec 25 01:42:02 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'pdns4.ultradns.org//IN':  
2001:503:ba3e::2:30#53
Dec 25 01:42:02 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'pdns3.ultradns.org/A/IN':  
2001:dc3::35#53
Dec 25 01:42:02 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'pdns4.ultradns.org/A/IN':  
2001:503:c27::2:30#53
Dec 25 01:42:02 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'pdns4.ultradns.org/A/IN':  
2001:503:ba3e::2:30#53
Dec 25 01:42:02 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'pdns4.ultradns.org/A/IN':  
2001:7fd::1#53
Dec 25 01:42:02 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'pdns3.ultradns.org//IN':  
2001:7fd::1#53
Dec 25 01:42:02 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'pdns5.ultradns.info/A/IN':  
2001:500:19::1#53
Dec 25 01:42:02 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'pdns5.ultradns.info/A/IN':  
2001:500:1a::1#53
Dec 25 01:42:02 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'pdns4.ultradns.org//IN':  
2001:500:40::1#53
Dec 25 01:42:02 storage000 named[29649]: lame-servers: info: error  
(network unreachable) resolving 'pdns4.ultradns.org/A/IN':  
2001:502:4612::1#53


That tells me your IPv6 connectivity is probably broken. Either fix  
it or disable IPv6 in named by starting it with -4.





So Bind's 'lame' log line includes the concept of 'unreachable'?  I  
seem to recall

the definition 'delegation target that answers without aa'.

However, given the '(network unreachable)' comment, I agree with your  
diagnosis.


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

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


Re: Cache only and reverse mapping

2011-12-16 Thread John Wobus

On Dec 16, 2011, at 11:22 AM, sasa sasa wrote:
I'm trying to setup a DNS for an ISP, this ISP's DNS is in  
delegation tree (answering world), and I know about cache  
vulnerabilities so I was wondering what is the best solution for ISPs?
By separating cache from authorities, you mean implementing 2 DNSs  
(2 different IPs)? This doesn't sound practical.



Then I suspect you know all this, but...

The practicality certainly depends upon your site's situation.  Many
sites have enough IPs to allocate a few more to DNS, and enough server
capacity to run more bind instances, but I imagine some don't.

Two such bind instances could be on different hardware or the same,
but two IPs would be necessary.  Bind typically runs on OSes that,  
without
tricks such as natting, generally support just one program listening  
to a specific
port/ip.  Bind's "view" feature allows a single bind instance on a  
single IP to
act like a bit like two instances, offering some of the advantages of  
isolating

their respective functions.

Aside from this, a bind instance can be configured not answer queries
to non-authoritative data from outside your address space.  This also  
gives
you some of the risk advantages you'd get from running separate  
instances.


John Wobus
Cornell University
___
Please visit https://lists.isc.org/mailman/listinfo/bind-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 only zone?

2011-12-16 Thread John Wobus

If CloudFlare is similar to Akamai's solution, recursive servers never
see the CNAME record.  Instead, when the auth server receives the  
query

for the A record of the apex, it performs its own query for the CNAME,
and returns the result of this.


In other words, if your theory is correct, this "CNAME"
is window dressing for the customer ("yes, they gave me a
CNAME, I'm happy!") while actually they serve A records
that they've specified to give the same answer as "whatever
address the A record of such-and-such name has".  What they
present in their customer interface or store in their
zone-file-equivalent is arbitrary.

Makes DNSSEC interesting.

It's always helpful to be able to tell your customer "yes, we gave
you a CNAME, just like you asked for.  We do it even if our competitors
say no!"

John Wobus

P.S. Hm, I wonder if a TLD will give me a three part CNAME:
if they've given me "example.com. CNAME foo", will they also give
me "www.example.com. CNAME foo"?

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

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


Re: Cache only and reverse mapping

2011-12-16 Thread John Wobus

On Dec 15, 2011, at 3:07 AM, sasa sasa wrote:
For an ISP, is there any risk in configuring BIND DNS as cache only  
and adding customer's reverse mapping zones?


If this copy of the reverse zone is for the world's use (i.e. in the  
delegation tree), then your DNS server would
be answering queries from the world, and a caching server answering  
queries from the world is vulnerable to known
cache vulnerabilities in the DNS protocol.  On the other hand, if this  
copy of the reverse zone is only to answer
your customer's queries, and the DNS server is configured not to  
answer queries from the world, then you've avoided
the DNS protocol vulnerabilities and there's no special risk attached  
to serving this zone.


Aside from the issue of preventing known cache vulnerabilities in the  
DNS protocol, folks often separate
caching from authoritative (specifically, in the delegation tree) as  
an insurance policy against bugs and
vulnerabilities that haven't been found yet.  It's hard to quantify  
risks associated with bugs and vulnerabilities

that no one has found yet and may not even exist.


Any other possible implementations?


We'd have to know what you're trying to accomplish.

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

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


Re: split horizon and zone transfers to secondary DNS servers

2011-12-02 Thread John Wobus

Notifies are also a challenge. The two solutions are:

-Use TSIG for the notifies and zone transfers.
-Use extra IPs: on each primary and secondary, set up an IP
address dedicated to notifies and transfers for a specific view.
Your first view can use your preexisting IP but each additional
view also gets an IP of its own.

With the latter solution, depending on the situation, you might
figure out some short cuts.  But TSIG looks awfully attractive
in comparison.

The book DNS & BIND Cookbook addresses the issue.

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

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


Re: Algorithm 'When to use EDNS0'?

2011-12-02 Thread John Wobus

On Nov 30, 2011, at 4:39 PM, Mark Elkins wrote:

All this comes about as I had the expectation that DIG would run in a
similar way to any other 'dns lookup' - which it currently doesn't.


It is what it is, but I've always considered dig to be a tool
aimed at giving you a means of doing lookups independent of your
client's dns-related behavior and configuration.  It's the one
widely-distributed tool with that property.  Such a tool
is invaluable when trying to determine or confirm specific server
behavior.

John Wobus
Cornell U


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

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


Re: Port number in A record in zone file

2011-11-17 Thread John Wobus

On Nov 17, 2011, at 8:51 AM, Rick Dicaire wrote:

On Thu, Nov 17, 2011 at 8:46 AM, Aleksander Kurczyk
 wrote:

Hello,
Yesterday I asked here how can I run multiple named processes on  
different ports in one OS. Now I have some troubles with that. How  
can I specify the port number in zone file A record?


You can't.



nameservice SRV record?  :)

John

P.S. I'm fully aware that no DNS record is of any use if
clients don't look it up.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: trigger point for new bug

2011-11-17 Thread John Wobus

On Nov 16, 2011, at 4:20 PM, Michael McNally wrote:


On 11/16/11 9:55 AM, Chris Brookes wrote:

Any info on whether the newly announced bug can be triggered before
the query ACL is applied on a recursive only server? An authoritative
only server ought to be safe?


According to our best current understanding of the issue:

+  Authoritative-only nameservers should be safe and only
  recursing servers at risk.


How about authoritative-only views?  I.e., if a query reaches
the bind instance but is in a view that does not have caching,
could it crash the instance? (I assume not.)

Also, folks who had problems: did anyone have a crash
by a bind instance that cannot receive queries from the outside
world?  I.e. incoming port 53 firewalled by the server or
an external device.

My assumption is that the crashes were typically triggered
by sites's own DNS queries, but it would be nice to
confirm that some site knows their crash happened that way.

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

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


Re: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed

2011-11-17 Thread John Wobus

I assume ISC does not deliberately insert aborts
triggerable by bad data in DNS queries and answers.
Much more likel,y they do it when something happens
that is supposed to be logically impossible whatever the
incoming data, and implies continuing to run is
potentially insecure and/or will just create a
subsequent, more obscure crash.  I assume the fact
that bad data triggered an abort is due to a bug.

That said, in this case they might be changing this
specific abort to a warning, fixing up what state
they can and crossing their fingers.

John


On Nov 16, 2011, at 7:35 AM, David Ford wrote:


can we have a paradigm shift from ISC please?  instead of falling over
dead with insist/assert, please bleat a warning and drop the  
problematic

issue on the floor instead and press on with business.  many BIND DoS
attacks (and zone typos) are very effective for just this reason.

:)

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


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


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

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


Re: NXDOMAIN redirection in BIND 9.9

2011-09-30 Thread John Wobus
. . . both Evan's blog post  and the announcement of next week's webinar include NXDOMAIN  
redirection as the first new feature. I'm really surprised by that  
- is this something that BIND users were clamoring for?


Yes.


I'm a BIND user who is clamoring to keep such a feature out of BIND.

John

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

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


Re: DNS-cache with custom gTLDs

2011-09-23 Thread John Wobus

2011/9/23 Kevin Darcy:
You're almost certainly getting the NXDOMAIN because you're spoofing  
the
root servers, and your "fake" root servers don't have the same  
knowledge as
the real ones, so they'll return NXDOMAIN for some queries (whereas  
dig
+trace does not, because it follows the hierarchy down and asks  
different
nameservers). In other words, you're shooting yourself in the foot  
with your

hints-file trickery.


That was my thought as well.  Sometime NXDOMAINs also could simply be
inconsistent authoritative data at the other end.  Once again, building
a kluge to work around such a thing wouldn't be a good strategy.

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

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


Re: Max Cache Objects

2011-09-23 Thread John Wobus

Is it possible that your DNS performance issue isn't a
cache issue? For example, does your system need to
invoke bind with -4?

John

On Sep 21, 2011, at 5:00 PM, TMK wrote:


I have couple of questions.

bind cache memory limit is 4GB. can I increase it. or this is hard- 
coded limit.


i'm running the x64 bit version.

also to increase the cache hit ratio I have created script to query my
dns for the top 1 million sites. would this give any performance
advantages or is it useless.

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


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


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

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


Re: bind 9 performance

2011-06-17 Thread John Wobus

Delegation records caught us too.  There used to be a
document called something like "top 10 things to pay attention
to when you upgrade from bind 8 to bind 9" which included
this gotcha, and I'd wished I'd paid real attention to it.
But it was easily fixed once the problem was understood.
We found bind 9 to use more memory and cpu, but this
was easily handled by normal server replacement.

If your site has not too much of anything specific, e.g. 20
zones, 2000 names, 500 desktops using it, one public website
with 10,000 hits a day, I expect it is extremely difficult
to buy a current computer slow enough to have any trouble with
bind 9.  A modern $300 laptop would be practically idle.

But if your server is very old, or if there is some aspect
of your configuration/site that is scaled up or advanced
features that you use, you may have to read more,
tune, benchmark, etc.  If your spam filter retrieves
its data via dns records, that could push up your
query rate and cache size.

John Wobus


On Jun 15, 2011, at 5:52 PM, Mark K. Pettit wrote:

One of the things that got us is we didn't know BIND 8 automatically  
created delegation records in a zone at the zone cut, if the  
nameserver knew of the existence of the cut.


For example, if we have the following zones in our named.conf:

 zone "example.com" { ... };
 zone "sub.example.com" { ... };

and inside example.com, we do *not* have any delegation records for  
"sub.example.com", BIND 8 will automatically create the NS records  
in example.com.


BIND 9 will not do this.  Be sure all of your zones that have zone  
cuts also have the proper delegation records.


On Jun 15, 2011, at 1:30 PM, Eivind Olsen wrote:


abushla...@ies.etisalat.ae wrote:


What about zone configuration in BIND 8 and BIND 9? Is there any
difference between the two ?


Do you mean the zone configuration in named.conf, or the zonefiles?

BIND9 has a doc/misc/migration document which gives plenty of good  
advice

on configuration changes from BIND8 to BIND9.

In general, what I'd recommend is:

1) Read that migration document
2) Test your existing named.conf + zonefiles by either loading them  
into
BIND9 directly, or by using the named-checkconf / named-checkzone  
commands

from BIND9.
3) Watch your logs

Regards
Eivind Olsen


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


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


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

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


Re: BIND 9.7 Serial Number Decrease Problem

2011-06-17 Thread John Wobus

Barry Finkel wrote:

I ran a test this morning on one of the Solaris 10 slave servers.
A query to the server showed serial numbers:

 _tcp   1238
 _udp842

Both of these match the zone on the MS Windows DNS Server.
I checked the zone files on the slave server:

 _tcp   1239
 _udp843

Both of these are increased by one from what BIND returns in
response to a query.

The two zones have NO .jnl files.

I did

 ./rndc stop
 <>
 /etc/init.d/named.anl start;tail -f /var/adm/messages

Once BIND started, the serial numbers were INCREASED, as I
expected they would be, given the lack of .jnl files.

And a few minutes later BIND complained about the serial
number on the master being less than that on the slave
for both zones.  I consider this a bug in BIND 9.
What further diagnostics do I need to get?

I have another Solaris 10 slave on which, I assume, I can
duplicate this.  And from past experience, in one day, after
the zone has expired and been refreshed, I will be in the same
state on this slave.


Do bind slave instances EVER make up or increment serial
numbers?  This just seems like such an unlikely bug
that bind would start doing that.  Could it be that
the supposed slave instance is accepting dynamic updates?

I'd be tracing/tracking SOA files on the master, and communications
between the dns instances very closely before I'd even
give such a potential bug much thought. Perhaps there are
bind functions that I'm not aware of and I'm wrong.

John

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

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


DNSSEC versus multiple views

2011-05-31 Thread John Wobus

What problems do sites have that deploy both multiple views and
DNSSEC?

I read the "Split-View DNSSEC Operation Practices" draft, which
outlines a number of set-ups, generally citing disadvantages in the
area of administration, troubleshooting, and added complexity.  But
it says these set-ups are workable.

Our site serves thousands of mobile users with many types of consumer
mobile devices used onsite and elsewhere.  Our site also has
independent departments running their own caching servers.  Both
these make me nervous.  I could imagine a future where mobile devices
both cache and validate DNS and could imagine the combination of
multiple views and DNSSEC creating problems for them.  Perhaps
future end-user caching/validation procedures will be driven by the
existence of multiple-views/DNSSEC sites.

All this is from reading and thinking.  Can anyone tell me about
real-world problem cases?

John Wobus
Cornell University

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


Re: how to check if a slave zone is expired

2011-05-06 Thread John Wobus

I try to catch zones that are not updating on the slaves
to which I have access.  I compare the modtime of the zone
file with the current time and the refresh interval
for the zone.  Typically I allow a failure or two
before alerting, e.g. wait 1 refresh + 2 retry intervals.
If the expire interval is very short, this could
be too late.

Depending upon the expire interval and refresh interval,
the window in which you can be alerted and troubleshoot
a problem might be short.  If you're slaving zones
for another site, you might not have control of that.

If you find out refreshes aren't happening long before
the expiration, and if the zone is pretty static (e.g. a single
www.example.com address), you don't have to jump very fast to
address things if the expire interval is weeks.  If folks are
depending upon records that are dynamic, you want to respond
pretty quickly.

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


Re: AW: ipv6 PTR in zone file

2011-04-15 Thread John Wobus

pint> use Net::IP
pint> $foo = new Net::IP '2001:db8::42'
3
pint> $foo->reverse_ip()
2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d. 
0.1.0.0.2.ip6.arpa.

pint>


Or you could just dash off the simple perl expression to do the job:

my $ptr = do {
my($head,$tail) =
  map { join '', map { sprintf '%04s',$_; } split /:/,$_; }
  split /::/, $addr  . '::', 3;
my $hex32 = '0' x 32;
substr( $hex32, 0, length($head) ) = $head;
substr( $hex32, 32, -length($tail) ) =  $tail;
join '.', ( reverse split //, $hex32 ), 'ip6.arpa';
};


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


Re: priority with A record?

2011-04-08 Thread John Wobus

All the previously-mentioned issues apply, but (obviously)
round robin could be made to offer a select server twice as
often by giving that server an additional address and
A record.  Something similar for nameservers could
be devised.

I had a vague recollection that one could simply
duplicate an A record in the zone file, but perhaps my
memory is playing tricks on me.

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


Re: Bogus Wild Card DNS

2011-04-08 Thread John Wobus

On Apr 8, 2011, at 10:58 AM, Martin McCormick wrote:


I am trying to set up bind9.7.2P3 in a special manner such as is
used in network registration setups in which named always
returns the address of a registration server except for a few
other domains that supply updates and antivirus scans, etc.

In this case, I have microsoft.com as the one allowed
domain and everything else should return the wild card A record.
What is happening right now is that the one special allowed
domain works fine and all else returned a SERVFAIL rather than
resolving to what will eventually be the registration server.
The microsoft allowed zone is defined in named.conf with
forwarders
My understanding is that the only real zone one needs is the
hint zone or "." and here is mine:

@ IN NS netreg.it.okstate.edu.
microsoft.com.  IN NS netreg.it.okstate.edu.
* IN A 139.78.6.193

Why am I not getting resolution to 139.78.6.193 for any
other query?

The log isn't complaining about much of anything but any
query that is not microsoft returns that SERVFAIL message.

I must remind anybody experimenting with something like
this to be sure to put a bogus DNS clause in your functional
production DNS's so that anything that might somehow leak out of
this experiment is treated as junk and ignored.

Many thanks.


Martin McCormick WB5AGZ  Stillwater, OK
Systems Engineer
OSU Information Technology Department Telecommunications Services  
Group

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


I think you want a *.com entry as well as the * entry.
The existence of the 'microsoft.com.' record, believe
it or not, affects whether names of the form whatever.com
match the * A record.

DNS's rules for wildcarding have been known to trip
up a lot of people, so look for a full explanation.

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


Re: dns RR method is not equal balanced?

2011-03-31 Thread John Wobus

On Mar 29, 2011, at 10:49 AM, Tony Finch wrote:

Kay  wrote:


some domain has 12 IPs but traffic of the server is not equal.
The traffic of 11 IPs is same and just 1 IP is higher than others.


If you use round-robin DNS you are relying on the clients not to muck
around with the responses they get from your DNS server. If they sort
them, for example, that will mess up the balancing. For example RFC  
3484

screws it up.



In theory, if the glsb can be configured to act the way bind does,
you could isolate the problem to client behavior.  Obviously
bind's round-robin behavior could be checked "in the lab"
with a test name.

Seems unlikely given your description, but if the clients vary
as to how much load they impose for each DNS lookup they do,
you're more likely to see imbalances.  For some clients, TTLs
might contribute to this.  However, given enough time, the
pattern should shift, i.e., it wouldn't always be that this
one IP gets most of the load.  If the clients are daemons
that stick to a server for months based upon a single
DNS lookup, then this time might be very long.

If you're dealing with typical web hits, such a scenario
is unlikely.

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


Re: ip6.arpa help

2011-03-18 Thread John Wobus

On Mar 18, 2011, at 5:07 AM, mattias.o.anders...@gavle.se wrote:


Hi,

I work for a small ISP in Sweden and we recently starting to provide  
IPv6 for customers. I have a problem thou with the reverse DNS  
lookups for IPv6. I don’t have a good way of doing this, maybe  
someone can help.


When we deliver IPv6 service to a customer they get at least a /64,  
which you all know is A LOT of addresses. This is impossible to  
generate unique PTR records for every address. The way we solved  
this is to use “* PTR customer.domain.com.” so that all addresses in  
the /64 will get the same reverse lookup. But if a customer need a  
unique PTR for a mailserver I cant use both “*PTR  
customer.domain.com.” and “5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR  
mail.domain.com.” in the same zone-file, the * will be ignored. Is  
this how it should be or am I doing it wrong?
Instead maybe Bind can dynamically generate a answer for a reverse  
lookup request instead of storing all PTRs in the zone-file?


Are there any good information, maybe RFC,  how reverse DNS should  
be done in IPv6. Then I don’t mean how to register a ip6.arpa and  
edit your zone-file in bind. I mean how you solve the problem with  
generate 2^64 unique PTR records for a single customer without  
filling your hard drive. =)


Cheers // Mattias Andersson




How about just 16 records per such server?  A lot less
than 2^64, and the extra records could be generated by
script.

5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR mail.domain.com.
5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.* PTR customer.domain.com.
5.2.0.0.0.0.0.0.0.0.0.0.0.0.* PTR customer.domain.com.
5.2.0.0.0.0.0.0.0.0.0.0.0.* PTR customer.domain.com.
...
5.2.* PTR customer.domain.com.
5.* PTR customer.domain.com.

I believe that the serving of * is determined by RFC, so while BIND
could have its own mechanism to generate records on the fly,
it can't/shouldn't do something different with *.

I suspect that IPV6 PTR records might fall by the wayside
for the general end user, especially since mainstream
IPV6 practices are still being formed and are likely tend toward
what is practical.  Automatically-generated PTR records have
limited value, and *just might* make DNSSEC quite a challenge.
Some other, more practical method may well be devised for ISPs to
show what address space they are making use of.  (For example,
the powers-that-be could choose to provide two top-level PTR
domains for IPV6: one for full records, and the other for
subnet-wide wildcards.)

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


Re: dots in hostnames problem

2011-03-11 Thread John Wobus

On Mar 10, 2011, at 4:24 PM, Matt Rae wrote:

Thanks guys, sounds like a solution would be to transfer the zone
files outside of bind. I'll give some of the suggestions a try.

Matt


I can't help but be curious.  What problem would be solved by
transferring the zone files outside of bind?

John



On Wed, Mar 9, 2011 at 1:01 PM, John Wobus  wrote:

On Mar 9, 2011, at 1:09 PM, Matt Rae wrote:


Hi, I'm working on setting up a slave dns server. Dots have
historically been used in the hostnames here. The dots cause the
resulting zone file from a zone transfer to have $ORIGIN  
automatically

set assuming the dots are indicating a subdomain.

Here's an example of what's happening:

master zone file:

$ORIGIN example.com.
host1.set1Ax.x.x.x
host2.set1Ax.x.x.x
host3.set1Ax.x.x.x

slave's zone file after axfr:

$ORIGIN set1.example.com.
host1   Ax.x.x.x
host2   Ax.x.x.x
host3   Ax.x.x.x

Is there a way to have it not change the ORIGIN and assume the dots
are a subdomain?


I bet you can't change that, but it doesn't
matter to Bind or the DNS.  The two files
mean the same thing.  ORIGIN doesn't
"assume" anything about subdomains: it's
just a convenience for abbreviating the
file.

If you need a consistent format for
some purpose, you could use the output
of named-compilezone.

John

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



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


Re: dots in hostnames problem

2011-03-09 Thread John Wobus

On Mar 9, 2011, at 1:09 PM, Matt Rae wrote:

Hi, I'm working on setting up a slave dns server. Dots have
historically been used in the hostnames here. The dots cause the
resulting zone file from a zone transfer to have $ORIGIN automatically
set assuming the dots are indicating a subdomain.

Here's an example of what's happening:

master zone file:

$ORIGIN example.com.
host1.set1Ax.x.x.x
host2.set1Ax.x.x.x
host3.set1Ax.x.x.x

slave's zone file after axfr:

$ORIGIN set1.example.com.
host1   Ax.x.x.x
host2   Ax.x.x.x
host3   Ax.x.x.x

Is there a way to have it not change the ORIGIN and assume the dots
are a subdomain?


I bet you can't change that, but it doesn't
matter to Bind or the DNS.  The two files
mean the same thing.  ORIGIN doesn't
"assume" anything about subdomains: it's
just a convenience for abbreviating the
file.

If you need a consistent format for
some purpose, you could use the output
of named-compilezone.

John

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


Slaves and views

2011-03-04 Thread John Wobus

Hi,

Can a zone file a slave in one view and the same zone file
be served by another view?

I'm going to split our authoritative servers into internal
and external views.  My question concerns zones that we
secondary for other organizations, slaved to masters at
their sites.

I know I could configure each of their zones with separate files
in each the two views, listen/use an additional address that
accesses our local view, and tell these peer organizations to
notify and allow transfers from this additional address.
I'm not (yet) worried about dynamic updates, if there are
any.

Is there a way I can handle their zones without making
these other sites configure another address, and I still
run just one bind instance?

Other ideas are: running a separate bind instance for
these zones, or making one view a slave to the other.
Possibly forwarding of some kind, another thing I haven't
done much.

John Wobus
Cornell

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


Re: Help with unresolvable domain (subdomain, actually)

2011-03-04 Thread John Wobus

Then the load balancer should return default records or 0.0.0.0/:: to
indicate the name is good but doesn't currently have a address.
I like that solution, actually. Even if the client doesn't recognize  
it

as a "special" address, hopefully if it tries to connect to it, the
packet won't make it past the first router or switch hop...

Has anyone proposed this to the load-balancer vendors?


Isn't this just a specific instance of configuring a load balancer's
fallback address?  E.g., when server A and B are both down, give  
address of

server C.  Some load balancers allow configuration of a server D to
be used only if C is down as well.  Address C or D could be configured
to be 0.0.0.0 and configured with no test for "up-ness".

(Not that I'm completely happy with 0.0.0.0 or any other address that
local folks could conceivably have figured out some crazy use for.)

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


Re: How to allow set Host file dns query priorities in BIND

2011-02-25 Thread John Wobus

On Feb 23, 2011, at 12:19 PM, Kevin Darcy wrote:


Unless one intimately knows the failure behavior of
*every*single*app*and*subsystem* in one's environment (which in a
large/complex environment is a constantly moving target, since new  
apps

and subsystems are being implemented all the time), one should err on
the side of safety and ensure that DNS resolution still works even if
the resources that the address  (A/) records point to is  
unavailable.


Ah yes, but for any given application, how do we know which is safer?
Failure to resolve the name?  Or resolving the name and then failing
to connect?  If an app doesn't handle some error conditions
well, why is it safer to assume a priori that one specific error
(failure to connect) is handled well and another (failure to resolve
the name) handled poorly?  By resolving the DNS to something,
we could be making things worse.

If we establish that a critical app can handle a failure where name
resolution works but connecting to the service does not, but cannot  
handle

a failure where name resolution doesn't work, and the app cannot be
fixed, then yes, we have an incentive to provide some type of name
service that always resolves to something or other.  We also have
an incentive to get rid of that app, tell others about its weaknesses,
etc.

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


Re: what's a valid domain name?

2011-02-04 Thread John Wobus

So 10.14.22.11 is a legal hostname, right?

We had a recent experience where our DNS administration
system allowed someone to insert in a CNAME record that
resembled this:

www.example.com. CNAME 10.14.22.11.

A fascinating thing about this is that my computer/browser could
take me to www.example.com just fine.

John Wobus
Cornell



On Jan 30, 2011, at 7:30 AM, p...@mail.nsbeta.info wrote:



From RFC 1123

   One aspect of host name syntax is hereby changed: the
   restriction on the first character is relaxed to allow either a
   letter or a digit.  Host software MUST support this more  
liberal

   syntax.




p...@mail.nsbeta.info writes:


Joseph S D Yao writes:



The labels must follow the rules for ARPANET host names.  They must
start with a letter, end with a letter or digit, and have as  
interior

characters only letters, digits, and hyphen.  There are also some
restrictions on the length.  Labels must be 63 characters or less.



A label must start with a letter? oh I don't think so.
How about these domains which all have huge DNS traffic?

163.com
126.com
51.com
56.com

yes 163.com is a domain name but "163" also can be treated as a  
label for

domain "com.", is it?

Thanks.

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

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


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


Re: what's a valid domain name?

2011-02-04 Thread John Wobus

To add to the story, I added a rule to our DNS administration
system that we'll only allow hostnames that include
at least one alphabetic.

John

On Feb 4, 2011, at 11:26 AM, John Wobus wrote:


So 10.14.22.11 is a legal hostname, right?

We had a recent experience where our DNS administration
system allowed someone to insert in a CNAME record that
resembled this:

www.example.com. CNAME 10.14.22.11.

A fascinating thing about this is that my computer/browser could
take me to www.example.com just fine.

John Wobus
Cornell



On Jan 30, 2011, at 7:30 AM, p...@mail.nsbeta.info wrote:



From RFC 1123

  One aspect of host name syntax is hereby changed: the
  restriction on the first character is relaxed to allow either a
  letter or a digit.  Host software MUST support this more
liberal
  syntax.




p...@mail.nsbeta.info writes:


Joseph S D Yao writes:



The labels must follow the rules for ARPANET host names.  They must
start with a letter, end with a letter or digit, and have as
interior
characters only letters, digits, and hyphen.  There are also some
restrictions on the length.  Labels must be 63 characters or less.



A label must start with a letter? oh I don't think so.
How about these domains which all have huge DNS traffic?

163.com
126.com
51.com
56.com

yes 163.com is a domain name but "163" also can be treated as a
label for
domain "com.", is it?

Thanks.

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

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




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


Re: why queries rejected?

2011-01-21 Thread John Wobus

It might not be your bug.  It might be other sites.

As was said, bind can log info that would help
explain it.

Or if the number is rising continuously, you can capture a
bunch of dns queries with tcpdump or a similar program
and look over a sample of the rejected queries.

On Jan 18, 2011, at 9:03 PM, p...@mail.nsbeta.info wrote:

My zone is game.yy.com, and there are so many "auth queries  
rejected" in
named.stats which was generated by "rndc stats". Could you show me  
some way

to debug it? Thanks.

[game.yy.com]
 671834 auth queries rejected
   3003 recursive queries rejected
 685192 queries resulted in successful answer
 685891 queries resulted in authoritative answer
676 queries resulted in nxrrset
 23 queries resulted in NXDOMAIN
  4 requested transfers completed
  7 updates completed



p...@mail.nsbeta.info writes:






You haven't provided enough information for us to know. Have you
bothered checking logs?



Nothing special in logs from what I checked.


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


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


Re: clarification

2010-10-22 Thread John Wobus

On Oct 22, 2010, at 8:31 AM, rams wrote:

I have a record in BIND as follows:

mxdomain.com. 86400 IN MX 65536 gmail.com.

When I query "mxdomain.com." with type MX. What is the bind  
response. Is there any RFC mentioned about this .


On the wire, the MX preference is carried in a 16-bit field,
which cannot store 65536: the field simply isn't big enough.  If you  
query

an MX record and get a preference of 65536, the software with which
you are doing the query has a bug in it and is displaying something
that did not come from the server.

If a zone file has a preference of 65536, dns server software (such
as bind) that attempts to load the zone file should reject it as
impossible to use.  If you have dns server software that doesn't reject
it, you will have to experiment to find out what it does with the input,
which should be easy to do.  It could conceivably use a legal number
instead, or it simply leave out that record.  RFCs merely say 65535
is the maximum allowed.  Specifying what to do when reading a
zone file that exceeds this maximum is one of an infinite
number of possible input errors that RFCs have nothing specific
about.

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


Re: no more recursive clients: quota reached

2010-03-26 Thread John Wobus
Typically you can increase the default without harm, e.g., double or x  
10 if you

have a recent-vintage server with typical memory and speed, but
something might be causing the behavior that is impervious to
such a change or that needs some other kind of attention.
Such a problem might solely stem from sheer load, but quite often stems
from queries that are not receiving answers and are just sitting there
until they time out.

One of your clients might be making up names and trying them:
many would receive negative responses but a percent would receive
no response and sit.  Or it could be that some specific locally- 
popular domain's
nameservers are down or unreachable.  Or it could be intermittent  
network

problems. Or some kind of long-term routing/connectivity issue, e.g. the
consequences of firewalling.

If there are short episodes with tons of these log entries, that hints  
at

short problems with your Internet connection, or a specific app that
is causing the issue when it runs.  If your Internet connectivity
goes away in such manner that packets "disappear", then the number
of outstanding recursive queries typically steadily rises until the  
quota

is reached.

If you look at the number of clients at random times and it is always
substantial and/or close to the quota, it may be that increasing the
quota is the right solution.

rndc lets you view the outstanding queries and see how long they've
been waiting, which provides a lot of insight into what is happening.

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


Re: Blacklisting private address range

2010-02-26 Thread John Wobus

On Feb 26, 2010, at 9:54 AM, Diosney Sarmiento Herrera wrote:

Hi!

 Sorry for the delay.

 It was very useful for me. Thanks!

 In our nameserver we do not apply the bogon filter to the bogus
addresses because it will change with time and we not know how update
them automatically.

 My question is that if it is useful to blacklist the private address
range(this addresses never change with time ;) ) so our nameserver  
will

never respond queries from this addresses.

 I ask if this is usefull because the private address range don't have
meaning of sense in Internet.

 Thanks!

--
 Diosney



Re discarding queries from private space that came from the Internet:

Many sites would handle this at the routing level so as to protect  
more than just
bind, and to allow you to make use of private space within your own  
network.
An access list on a router interface would assure none of your own  
network
receives packets from private space that actually originated outside  
your network.
An app like bind can't sort out whether the packet with a source  
address in

private space came from your own network or came from the Internet at
large.

But if you've arranged things so this bind instance never receives  
traffic
from your own private space (e.g. if you aren't even using private  
space),
then you could certainly add such filtering to bind's normal access  
list.


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


Re: Having multiple name servers - is it really necessary

2010-02-05 Thread John Wobus
Nameservers malfunction and networks in front of them malfunction.   
When this happens to the secondary,
then you suffer what you are reporting.  If you have only one  
nameserver, then such a malfunction can

leave you dead in the water.

I've run into the issue of updates to secondaries stopping for some  
reason, and then noticeable
symptoms set in much later (after the data expires), making  
troubleshooting require a look pretty far
back in time to identify the failure or change that caused the  
problem.  Setting long expire times lengthens
the time you need to look back.  Under various circumstances, I've  
addressed this issue two ways:
(1) Instead of using the DNS transfers, devise my own method of  
keeping the servers' authoritative data in
synch.  This can be very little trouble if you run all the servers  
yourself and you maintain the data on a third
server, e.g. in your own database: just load the data on all the  
authoritative nameservers instead of one.

But it's either more difficult or impossible if you provide dynamic DNS.
(2) Run scripts periodically to check SOA serial numbers and report if  
they are sitting longer than

they should out of synch.

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


Re: Migrating DNS servers, need advice on hardware

2009-09-25 Thread John Wobus

How can observer the query count? Is there a command or table or
something or is it just how many hits the systems gets on port 53
identified from some form of logging software?


BIND logs hit statistics periodically to syslog, and you can use "rndc
stats" to append statistics immediately to a file.  See the BIND  
manual

for details.



Other means:

The BIND manual tells how to turn on bind's query log, which is  
normally turned off for performance/resource reasons.
On a very lightly loaded DNS server, it can be left on, and on a  
medium-loaded server, it may be practical to

turn it on for a short while to collect some usage data.

On a Solaris system, snoop can help (as can tcpdump on other *nix  
systems), e.g. to get a frame of reference
regarding your load, inspect 1000 packets to port 53, measuring how  
many seconds it takes to collect them.

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


Re: no more recursive clients: quota reached

2009-08-28 Thread John Wobus

On Aug 28, 2009, at 8:59 AM, Dave Sparro wrote:

On Thu, Aug 27, 2009 at 12:17 PM, Niall  
O'Reilly wrote:

Lisa Casey wrote:

Aug 26 12:48:56 netlink named[295]: client 207.191.185.6#60614: no  
more

recursiv
e clients: quota reached



Any ideas on how I should go about solving/fixing this?


   I'ld suggest you check your connectivity and routing.

   We see this behaviour occasionally, but only ever as a
   consequence of a back-hoe incident or similar catastrophe  
which

   isolates one of our campuses where there is a local resolving
   server.



Although it may not be a problem on your end of the network.  You
could be seeing a spike in DNS queries because somebody really, really
wants to talk to a remote location that is having problems.

DNStop may be able to help you pinpoint what DNS queries are giving
you problems:
http://dns.measurement-factory.com/tools/dnstop/

Run it on the DNS server to see if there are any queries that you are
seeing get repeated continuously.

--
Dave


I concur.  1000 is a lot of simultaneous queries.  Perhaps your site
is busy enough to generate that many "legitimate" queries, but
hitting that 1000 mark can also be a symptom of something slowing or
black-holing queries.  When I've seen "quota reached" logging,
typically further investigation reveals that there were network  
connectivity

issues at the time.

Your example of 564/1000, if that's typical suggests that perhaps you  
truly do have enough
normal queries to top out occasionally.  On the other hand, if you  
usually see fewer than
100, but it occasionally shoots to 1000, that could be a specific app  
doing something
(e.g., monthly web access log analysis), but could also be network  
issues.
(In some cases, it might be useful to set up a separate nameserver  
dedicated to the

demanding app.)

The age of the queries can also be revealing.

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


Re: Transfer delays

2009-05-29 Thread John Wobus

As per the other answers I've seen posted,
such a delay is often caused by notifies not reaching the
slave from the master.  In such a case, you would not
expect a delay of a fixed time, but rather delays over a
limited range of times, e.g. up to 15 minutes.

A notify is a kind of DNS query, normally UDP.  Can you
do any kind of DNS query from the master to the slave?  Specifically
to/from the server's addresses that are being used by bind?
A firewall or network ACL could be preventing all queries
from master to slave, thus might block notifies.  The
zone transfer, in contrast, is a TCP query from slave to master,
and could work even if UDP queries from master
to slave are blocked.

As per the answers I've seen posted, you also
can look at notify-specific issues: either the master
or the slave could be configured in such a way as
to prevent the sending or receiving of them.  Both
can have logs of notifies sent/received, which you
can use to eliminate this as your issue.

On May 28, 2009, at 10:16 AM, Michael Di Martino wrote:


List Members,

This is a new and quite basic install of BIND-9.

I am experiencing a 15 min delay from the time a zone file is updated 
and reloaded w/ rndc and transferred to the slave server.


What could cause this delay. I am at a total loss. Please advise.



Michael DiMartino 


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



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


Re: can bind filter the result

2009-04-24 Thread John Wobus


On Apr 20, 2009, at 2:55 AM, Ken Lai wrote:

let's take an example. my DNS server called SrvA, the outer DNS server
called SrvB.

normally, the client sent the query to SrvA, and SrvA forwards it to
SrvB. and SrvA return a result which came from SrvB to the client.
unfortunately the SrvB sometimes will return a A record that is a
advertisement site ip to SrvA. so i dont want to respond  to client if
the returned IP address is the Advertisement site address.

filter the domain name may not be suitable.

thanks.


If I understand correctly, the goal is to avoid answering any queries 
for A records
where the answer points at any of a specific list of blacklisted IP 
addresses.


As has been said, such filtering does not fit will with bind or any 
typical DNS servers.  Ideas:
Periodically scan the cache for names pointing at these addresses, and 
dynamically create zones?
Run a very clever firewall config in front of the DNS server that 
filters out such answers?
Instead of doing something with the DNS, use access lists or custom 
routes in your routers to block the addresses?


In any case, if you "succeed" in addressing the problem by providing no 
answer,

you may find the solution to be unacceptable because of timeout delays.

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


Re: C/C++ version Load balancer DNS

2009-04-10 Thread John Wobus

On Apr 3, 2009, at 7:31 PM, MSP wrote:

This sollution which I am thinking is for some telecom application and
not for web browsers.
I  kown that TTL for my requirement should be ZERO, so that no cashing
happens.

Please tell why we can not use DNS sollution for this.


You can indeed use the DNS, but depending upon details, you could run
into problems.  As has been mentioned, ISPs could run nameservers that
impose a minimum TTL or even ignore it.  The client OS could do
the same.  The client app might do the same, or might look up the number
once and expect it to work for a long time.  Some simple tests would
answer the questions for the pieces under your control, but
if you need to serve clients across the Internet, you might be taking
your chances regarding the world's caching nameservers.

Also, depending upon specfics, it may be that you want to use a
short, non-zero TTL.

John

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


Re: [OT] zonedit.com and changing DNS servers from current provider

2009-04-10 Thread John Wobus

On Apr 7, 2009, at 5:36 PM, Michelle Konzack wrote:

Hmmm, my own DNS is working, but HOW can I test a foreign DNS stup?


If your own DNS works at your own site, you can see what the rest of the
world is getting by any of the following:
-To do a quick check to see that the world is getting the right 
records: try

recursive queries (e.g., dig) against opendns.com's nameservers.
-Do a series of non-recursive queries, following the delegation tree 
from

the root down to your zone's delegated authoritative servers.
-dig +trace does the latter for you.

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


Re: name server zone list

2009-04-03 Thread John Wobus
Besides all the methods discussed, you could invent your own zone that 
has this data in a format

of your choosing., e.g.

example.com.myzones.example.com TXT "example.com"
example2.com.myzones.example.com TXT "example2.com"

Then:

dig @nameserver axfr myzones.example.com

Your design creativity and your self-discipline in always adding a 
record for each zone are your only limitations.
If you wish to get really fancy, you could script the rebuilding of 
your named.conf file to do so using data

gathered with this dig command.

John

On Apr 3, 2009, at 9:15 AM, Sandy Mackenzie wrote:


Hi,

I want to be able to produce a simple list of the zones on my DNS 
servers.  Is there anyway to do this with dig or any other tool?  I 
can currently transfer a single zone with


dig @nameserver "zone" axfr

but I want to see all zones hosted on my DNS server.

--


Sandy Mackenzie

The contents of this e-mail message and all attachments are intended 
for

the confidential use of the addressee and where addressed to our client
are the subject of solicitor and client privilege. Any retention,
review, reproduction, distribution or disclosure other than by the
addressee is prohibited. Please notify us immediately if we have
transmitted this message to you in error. Thank you.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



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


Re: "stealth master" DNS Security

2009-03-27 Thread John Wobus

On Mar 25, 2009, at 5:20 AM, Ram Akuka wrote:


Is there’s any way I can encrypt the zone files in the slave server,
that way no one can have access to the actual zone data beside the
master server.
(if for example someone will hack to the slave DNS he won’t have the
zones data).


No.

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


Re: No name resolution when slave is down

2009-03-20 Thread John Wobus
Actually, master and slave has little (read "nothing") to do with 
whether the domain resolves.
What's relevant are the delegation records pointing to your domain and 
the authoritative
records for the two servers.  In a normal, straight-forward setup for 
one master and
one slave, both servers would be listed in the authoritative data as 
well as the delegation records
within the delegating zone, and if one server were down, the other 
server could be found

and queried.

John

On Mar 20, 2009, at 7:51 AM, Dennis J. wrote:


Hi,
This morning the slave in our nameserver setup went down and 
surprisingly none of the domains hosted on these system could be 
resolved anymore even with the master working perfectly fine.
When I send queries directly to the master it resolves the domains 
fine so I'm not sure why a failure of the slave leads to a total 
failure of the service.

Does anyone have an idea what might cause this behavior?

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



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


Re: Hostname Naming Compliance

2009-02-24 Thread John Wobus

It's an excellent idea to make your systems handle such hostnames
without problems (e.g. not crashing) when they run across such a
name on the Internet.

It's unfriendly to propagate such hostnames when doing so impedes
others' ability to do something.

It's against your own interests to propagate such host names if it
impedes others from doing something you'd like them to be able
to do, such as visit your website and buy your stuff, or answer your
e-mail.

The amount of harm in a specific instance depends upon what the
app does and who is trying to use and what client software they use,
etc.  But in any case, whatever problem there could possibly be
is easily avoided by simply not using underscores.

If we all decide to allow underscores in hostnames, we give future app
writers and users the best shot at avoiding problems if we run the 
change

through the RFC process so they can easily look up what the rules are.
However, some folks do promote and make use of these sorts of
Internet improvements without bothering to do that.

John

On Feb 24, 2009, at 2:24 AM, David Ford wrote:


Here's a question.  Are we incapable of dealing with things like
underscores in hostnames?  Is there any significant harm in adapting?

-david

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



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


Question re separating caching and authoritative servers

2009-02-20 Thread John Wobus

What are the good ways to let your local caching server serve your
own site's data even after a caching-server reboot during an Internet
outage? If the caching server locates your own authoritative data
through normal delgation channels, and cannot reach the roots and
TLDs, then your own local clients could be unable to resolve names
of local servers, etc.

Any especially good or bad practices? Things that have worked well
or poorly? Right now, I'm leaning toward having the caching server
transfer key zones.

John Wobus

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


Re: Disable cache in bind 9.6

2009-01-20 Thread John Wobus

Disabling the cache makes sense if the purpose of your
nameserver is to provide your authoritative zone data and you
have a different nameserver to handle your site's general
DNS queries.

TTL settings are part of authoritative zone data, which is
completely independent of whether you disable caching in the
nameserver.

On Jan 20, 2009, at 4:49 AM, Dmitry Rybin wrote:


Hello!

How to disable cache in bind-9.6? ttl=0 - bad idea.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



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


Re: Avoiding being used as DDoS reflector.

2009-01-19 Thread John Wobus

On Jan 19, 2009, at 5:02 AM, Leonardo Rodrigues Magalhães wrote:




Nathan Ollerenshaw escreveu:


I have an Authoritative BIND server. It is configured to only allow 
recursive queries from localhost, with recursion disabled for any 
remote clients.


If you attempt to perform a recursive query against this server, it 
will respond with a "query refused" packet, as this is what BIND does 
if you try to recursively query a server configured to disallow 
recursive queries.

[  ]
Any ideas? Anyone facing this same problem found a solution? I'd be 
glad to hear it :)




   if you're running authoritative only for localhost and is not 
answering network requests at all, then you could probably firewall 
incoming packets to UDP 53 port !!! Let the responses in, let the new 
requests out.


   i cant imagine anything simplier than that.


If you need 53 to answer for authoritative zones, you could run two 
bind instances, one for your caching server,
the other for the authoritative data.  Then a firewall or instance-wide 
black-hole config would take care of it.

Not too inspired a solution, but it's all I can think of.

I fear that what you are seeing is difficult to handle, thus may well 
become only more popular as time passes,
especially if it really does cause trouble for the victim. If the 
traffic is negligible for you, then does it really
hurt the victim?  How would they be harmed?  Is the victim someone who 
queries your authoritative
server enough to get some confusing "hits" of matching port, ID, and 
server of outstanding queries?  Even if you
block recursive error returns, would an attack using valid 
authoritative answers be equally harmful to the victim?


John

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


Re: Bind open to query from anyone

2009-01-06 Thread John Wobus

As you suspect, this is a bad idea.

Those who cannot query the server cannot poison the cache
using the loopholes in the DNS protocol, i.e. put false data in
your nameserver for names like www.google.com, www.yahoo.com, etc.
There can be other impediments to poisoning the cache in this manner,
but simply blocking such queries is an extremely effective way to
to totally eliminate a huge number of potential poisoners.

On Jan 5, 2009, at 6:15 AM, Chris Henderson wrote:


I've setup a secondary name server which works as a secondary or slave
name server for my zone or domain name. However, I have tested and
noticed that I can query for non-authoritative answers from my
secondary or slave name server from outside my network. That is, any
one can use my name server to query any host name, eg. www.google.com,
www.yahoo.com etc. Is this a bad idea? How can I stop this?

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



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


Re: Fresh (non cached) dig

2009-01-05 Thread John Wobus

I'm imagining you want a way to make dig act like the caching
nameserver and do what it would do and show you the answer.
dig +trace does something similar to this.  There is no nameserver 
operation

that dig could do to tell a caching nameserver to act differently
for one query.  You could clear the nameserver's cache, or even
clear the one name you are interested in out of the cache.

Sometimes querying another name in the domain you are interested
in is sufficient for whatever you are checking.

In certain situations, it can be very helpful to check someone else's
caching nameserver, so it is helpful to have a few such addresses
on hand.  These days, a lot of sites are closing their caching servers 
(go figure!),

and I've been using OpenDNS's servers.

On Jan 2, 2009, at 8:11 PM, Stephen Ward wrote:


For all my attempts to read the manual on DIG I can't find a way to do
something really simple.

Is there a way to dig a domain name so even if the results are in 
cache,

it will ignore these and re-read them? It's really from a testing
perspective I'm looking at this. I can mash the keyboard each time to 
try

and get a better handle on the query time, but there has got to be an
easy way to do this?



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



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


Re: checkzone

2009-01-05 Thread John Wobus

Running an awk or perl script along with checkzones should be able
to do this site-specific check (and others you might find helpful) 
quite easily.


On Dec 30, 2008, at 7:51 PM, Mark Andrews wrote:



In message 
<7227c6c70812300937s7a4be464h16db91c6ead84...@mail.gmail.com>, "Mike

 Zupan" writes:


I know of named-checkzone but it doesn't handle missing trailing 
periods on

CNAME's like I want it to

Are there any scripts out there that can better verify if a zone file 
is

correct.

For example named-checkzone says this line is ok

host IN CNAME host.domain.com

I know technically it is valid.. but anything out there that might 
check for

it?

Thanks again
mike


You want the "do what I mean not what I say instuction".

If someone want's to add code to check of for CNAME to
non-existant checks it should be easy.  Remember however
that CNAME to non-existant is normal for some zones.

RFC 2317 "parent" zones have lots of such CNAMEs.

The "host" example above would normally result in a CNAME
to name within the zone itself.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



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


Re: Issue with case changing from master on BIND 9 to slave on BIND 8

2008-12-15 Thread John Wobus

Some years ago, I had that issue.  The problem was that the
zone transfer compression mechanism could change the case
of individual names.  This was fixed in some release of bind
(after 9.2.1, if I remember correctly), and bind release notes
would pinpoint the exact version with the change.

The problem was that the compression mechanism would compress
a.example.COM and b.example.com by using a pointer to a single string,
in one specific instance, "example.COM".  When uncompressed
at at the secondary end, the names came out as a.example.COM and
b.example.COM.

John Wobus
Cornell University CIT


On Dec 15, 2008, at 10:51 AM, Ben Croswell wrote:

I reaching out to the list on what appears to be a very odd issue that 
happened over the weekend.
We had an issue where some internal domains had the TLD capitalized 
after the zone transfer.

i.e. foo.bar.com on the master became foo.bar.COM on the slave.
 I know that DNS is case insensitive but it caused an issue with apps 
that were misbehaving.


The master is BIND 9.2.1 and the slaves in question are 8.2.3.
The master zone has everything lower case, and BIND 9 slaves show them 
as lower case as well.
 A manual zone xfer on the 8.2.3 boxes to a different local directory 
than the actual named directory shows .COM.


I was wondering if anyone had experienced an issue like this.

And I understand both of those version are ancient and need to be 
removed  from the environment.


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

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


Re: check Availability before sending response

2008-12-03 Thread John Wobus
3DNSs sold because this is a messy function, that needs to know details 
of whichever application protocol
your setup uses.  I would think someone has developed an open-source 
bind add-on to do it, but I don't

know any off-hand.

Given a specific simple situation and specific server failure modes to 
be covered, there are probably a
million people who could write a script using normal unix tools to 
carry out the function and load the

data into bind.


On Dec 3, 2008, at 9:53 AM, Ken DBA wrote:


Hello,

Is there any way to make Bind check the server's availability before 
send back responses to clients?


ie, given the domain name www.site.com was pointed to 1.1.1.1 and 
2.2.2.2 in Bind.
When a client query for www.site.com, Bind will check the health 
status for these two servers. If one is unavailable,Bind shouldn't 
direct client's requests to it.


I know F5's 3DNS can do it well.But rather than 3DNS, is there any 
free way for this purpose? Thanks.



Ken.






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



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