I've never actually used RRL, but from the manual, it appears to default to a
/24 prefix length to determine whether IPv4 clients are "similar" enough to be
lumped in the same bucket, for RRL purposes. That might need to be tweaked,
depending on the profile of whoever is attacking/abusing you.
[ Classification Level: GENERAL BUSINESS ]
Dot "." instead of asterisk "*" as the zone name. Remove the "hint" zone,
since that doesn't apply when you host your own root zone.
You need a proper MNAME for the SOA RR too.
- Kevin
On Wed, Jul 21, 2021 at 11:18
[ Classification Level: GENERAL BUSINESS ]
I've done the match-destinations/query-source thing before, but in addition
to that, it should theoretically be possible to also use a shared cache
between the views, via attach-cache. I've never played with that directive
myself, however.
[ Classification Level: GENERAL BUSINESS ]
That chapter doesn't show any PTR records, for the reverse zones of any
*public* address range, pointing back to a "localhost" name. It only shows
a PTR record in the reverse zone for the 127.0.0/24 private range, which is
what enables a reverse lookup
[ Classification Level: GENERAL BUSINESS ]
I just checked the ARM, and it denotes that "match-recursive-only"
(boolean) still exists for views. So, you might be able to set up a special
view with that, as well as a negated match-clients, specifying allow-query
{ none; }. Put it as the first view,
[ Classification Level: GENERAL BUSINESS ]
Duplicate RRs are suppressed, as per the standards.
RFC 2181, Section 5:
Each DNS Resource Record (RR) has a label, class, type, and data. It
is meaningless for two records to ever have label, class, type and
data all equal - servers should
[ Classification Level: GENERAL BUSINESS ]
Ivan,
I've never done the Let's Encrypt thing myself, but from my skim
of the documentation, it appears they want you to place a TXT record in a
specific part of your domain's namespace hierarchy.
I sincerely hope you're not trying to write
[ Classification Level: GENERAL BUSINESS ]
It's not a "BIND" solution, per se, but if you have a
sufficiently-sophisticated IPS (Intrusion Prevention System) you could have
it simply drop all queries of a particular QNAME, or any particular
combination of QNAME, QTYPE, QCLASS, before those
, a dynamic,
reputation-based RPZ feed. See https://dnsrpz.info/ for more.
- Kevin
On Tue, Oct 20, 2020 at 10:45 AM Kevin Darcy
wrote:
> [ Classification Level: GENERAL BUSINESS ]
>
> According to securitytrails.com (for
[ Classification Level: GENERAL BUSINESS ]
According to securitytrails.com (for instance), there are over 3,000
domains hosted on ns2.honeybot.us (securitytrails only shows the first few
domains hosted -- to see more, one presumably needs a subscription to their
service).
If one of your clients
[ Classification Level: GENERAL BUSINESS ]
Or, if you absolutely *must* use the same namespace internally and
externally (oftentimes you can't talk the business out of that), your
internal version should be a more-or-less a superset of your external
version.
How you keep those in sync is up to
[ Classification Level: GENERAL BUSINESS ]
Offhand, it looks like the server side is configured to only allow
authenticated updates, but you're sending an unauthenticated one.
A more nuanced issue might be if the ID you're running the nsupdate as,
can't read the key files, so even though you may
[ Classification Level: GENERAL BUSINESS ]
You didn't dot-terminate covisp.net in the "zone" statement, so it may be
appending who-knows-what to one of its queries, and going awry.
nsupdate -d (or -D) shows all :-)
- Kevin
On Mon, Jul
[ Classification Level: GENERAL BUSINESS ]
Only thing that comes to mind is a constantly-running dynamic update script
that adds/deletes records to/from the RRset at random.
A more sophisticated version of the script would look at what answers that
have been given out in the recent past, and if
[ Classification Level: PUBLIC ]
To clarify, the OP didn't specify what DNS software they were using, only
the OS (Windows 2016).
If using Microsoft DNS, then as Mark pointed out, Microsoft has not
implemented regular shared-key TSIG. They have, however, implemented
GSS-TSIG, which, I believe,
phone dialing ..."
>
> Except that that proved to be so onerous that people often use "speed
> dialing" for commonly dialed numbers. (Not to mention the fact that
> people usually address their friends and coworkers by short names.)
>
>
> On Mon, 28 Oct 2019 12:19:35 -0
[ Classification Level: PUBLIC ]
My opinion? It's better to wean your users away from shortnames than to try
to cobble together kludges, on the client side or the BIND side, to support
a bad habit. Shortnames introduce ambiguity, lead to nasty surprises, are
inefficient and insecure. Just like we
[ Classification Level: PUBLIC ]
It's not clear to me from the marketing fluff whether EfficientIP is based
on BIND or not.
If it is, then consider that you have an open-source codebase, and the
eternal debate is whether open source is inherently more secure or not. On
the one side, is the
commending a null MX.
I've concurred that a "-all" SPF will help.
- Kevin
On Mon, Aug 19, 2019 at 8:07 PM Reindl Harald
wrote:
>
>
> Am 19.08.19 um 23:31 schrieb Kevin Darcy:
> > [ Classification Level: PUBLIC ]
> >
> > MXes are for *receiving
[ Classification Level: PUBLIC ]
MXes are for *receiving* mail of course. The request is about *sending*
mail.
Setting the SPF record to "-all" is probably about the best you can do,
since AFAIK there is no universally-recognized way to signal "domain X
never sends mail".
Ironically, in order
There's a huge amount of DNSSEC verbiage in the response to that query
(4931-byte response from the authoritative nameservers), when querying
with +dnssec. I'm guessing the resolver function of BIND might be having
trouble with DNSSEC validation. At least, that's a hypothesis. I'm not
familiar
Publish all 3 NSes.
Publish MX records with primary/failover preferencing.
Use a load-balancer (free or commercial, software/hardware/cloud-based) to
direct the web traffic.
- Kevin
On Wed, Jun 5, 2019 at 11:16 AM Roberto Carna
TBH, I haven't worked specifically with "static-stub", but with the classic
"stub", one would put a "null forwarders" statement in the zone definition
to inhibit forwarding.
I.e.
forwarders { };
- Kevin
On Wed, May 22, 2019 at 8:16 AM Ben Lavender
The simple answer is that you can do this with allow-recursion. Note that
"recursion no" is a big (instance-wide or view-wide) "off" switch for
recursion, so if you already have that set, you'll have to un-set it in
order to apply your allow-recursion controls in a granular fashion. You may
also
If you're doing stuff at really small scale, you can just define your own
root zone and put all of the records into it, including records in the
"phishing" subdomain, and any reverse records you care about (in the
"in-addr.arpa" and/or "ip6.arpa" subdomains). For that matter, if you only
have 1
Delegate needs.example.com from example.com and you should be set.
- Kevin
On Wed, Feb 20, 2019 at 3:40 PM King, Harold Clyde (Hal)
wrote:
> Could I just define needs.example.com as a zone in a separate file so:
>
>
>
> zone "example.com" { type master; notify no; file
As discussed in another thread, delegate the zone you want to forward, in
addition to defining the zone as "type forward". If you already tried a
"type forward" and it didn't work, it was probably because the delegation
was missing. It's a non-obvious requirement, but named needs to see the
zone
Define teamviewer.com as 'type
>> forward'".
>> >> >
>> >> >An also what is the benefit in defining a root zone with the
>> teamviewer.com
>> >> >delegated into it??? Because I put to work this zone just as a forward
>> >> >z
If you go with Anycast via BGP, make sure your network infrastructure has
"multipath" enabled, otherwise the traffic will be skewed to one node or
the other.
https://tools.ietf.org/id/draft-lapukhov-bgp-ecmp-considerations-01.html is
one source which summarizes some of the literature and standards
Another approach is to define a "fake" vitaminc.pro domain, point it at an
internal webserver (assuming you have a spare, or can spin one up for the
purpose), and see what clients are hitting it.
Of course, that assumes the communication is web-based. If it's some other
protocol(s), you'd need to
I've already posted a solution for this. Basically, "Define root zone.
Delegate teamviewer.com from root zone. Define teamviewer.com as 'type
forward'".
"Recursion yes" is implied. No views necessary. It doesn't make any sense
anyway, to have the same match-clients list for all of one's views,
in
> other contexts.
>
>
> Timothe Litt
> ACM Distinguished Engineer
> --
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed.
>
> On 12-Feb-19 17:45, Kevin Darcy wrote:
>
>
> Defi
Define root zone.
Delegate teamviewer.com from root zone.
Define teamviewer.com as "type forward".
"recursion no" is incompatible with *any* type of forwarding or iterative
resolution. Should only be used if *everything* you resolve is from
authoritative data, i.e. for a hosting-only BIND
I don't believe there is any logging category for this, even when zones are
enabled for Dynamic Update, in which case the versioning is done
automatically. There used to be a "journalprint" utility that one could run
against the .jnl files to show the update history. But, even if the
journaling
Offhand, sounds like your LAN is saturated so the queries might not be
getting to BIND in the first place. Or the replies aren't getting back.
It's unlikely that QoS is going to help this, you indicated that QoS was on
your "router", and that is typical -- usually QoS is found on WAN links.
9.5.5 is old -- upgrade.
But, to the architecture issue... sounds like you need an "internal root
with forwarding exceptions" setup.
- As per best practices, consider separating the recursive-resolver and
hosting functions into separate views, separate named instances (listening
on
The only scenario in which I could see this being accepted by the client,
is if the replacement is a CNAME, since that's a "universal" type. But it's
still unclear what the ultimate intent would be.
-
Kevin
On Thu, Nov 8,
My basic rule of thumb is: use forwarding when connectivity constraints
require it. Those constraints may be architectural, e.g. a multi-tiered,
multi-layer network for security purposes, or may be the result of screwups
or unintended consequences, e.g. a routing blackhole. Use forwarding to get
To be honest, I don't have a lot of experience running dig on Windows, but
I assume it would use the same resolvers as everything else, in which case
they're either statically defined (typically through Control Panel) or
assigned via DHCP.
One thing to consider, though: on Windows, resolvers tend
Offhand, it looks like 192.168.201.92 is giving SERVFAIL for anything in
the carag.local zone, but is fine for the olh.local zone. Did the zone load
properly? Look in the logs at startup or reload time.
But, the tools you're using, and how you're using them, makes
troubleshooting very difficult
One of the most useful initial steps in troubleshooting is to establish
your ability to reproduce the error.
So, I'd look at getting to the command-line of the originating resolver, if
possible, and using a command-line tool like "dig" to generate queries
towards the intended target and see if
You need to get to the root cause of what's causing the SERVFAIL.
Removing "forward only" just masks the problem by telling the resolver
algorithm to fail over to iterative resolution when it encounters the
SERVFAIL. So, sure, the query resolves, but probably not from the correct
server, and
I'll just toss in the factoid that NTP can be run on multicast or anycast,
which may negate some of the motivation for using a DNS name to access the
service.
- Kevin
On Wed, Sep 19, 2018 at 11:38 AM Andrew Latham wrote:
> On Wed, Sep 19, 2018 at 10:19 AM Ray
On 9/18/2014 12:33 PM, Martin G. McCormick wrote:
This is a perl module but my question is pure bind. Is
anyone familiar enough with this perl module to say whether the
packets are sent as TCP or udp? If udp, one would think that if
a packet was sent to do a job and the DNS failed to
You have multiple choices here.
Loopback is sometimes a bad choice, since the client may try to connect
to itself, and in pathological cases this could cause an infinite loop.
You could consider an A record with RDATA 0.0.0.0, the null or
unspecified address. It is not legal for that ever to
On 9/11/2014 3:47 AM, Matus UHLAR - fantomas wrote:
On 10.09.14 18:13, Kevin Darcy wrote:
No, what I'm saying is that if
example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then
where does 48.113.0.203.in-addr.arpa point?
Completely your decision
AM, Mark Elkins wrote:
On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote:
No, what I'm saying is that if
example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then
where does 48.113.0.203.in-addr.arpa point?
Some people will point it at example.com
On 9/11/2014 12:08 PM, Matus UHLAR - fantomas wrote:
On 9/11/2014 3:47 AM, Matus UHLAR - fantomas wrote:
On 10.09.14 18:13, Kevin Darcy wrote:
No, what I'm saying is that if
example.com owns an A record 203.0.113.48, and
www.example.com owns an A record 203.0.113.48, then
where does
On 9/11/2014 11:51 AM, Mark Elkins wrote:
On Thu, 2014-09-11 at 11:27 -0400, Kevin Darcy wrote:
Mark,
Depending on implementation, a PTR RRset with multiple
records either
-- only ever gets answered with the first record of the set (in
which case the second and subsequent records
On 9/10/2014 11:58 AM, Alan Clegg wrote:
On 9/10/14, 8:42 AM, Sam Wilson wrote:
And you could reduce maintenance very slightly by replacing
www in A 75.100.245.133
with
www in CNAME @
And now you have an MX record, 3 NS records and a bunch of other
On 9/10/2014 5:20 PM, Alan Clegg wrote:
On 9/10/14, 2:13 PM, Kevin Darcy wrote:
On 9/10/2014 11:58 AM, Alan Clegg wrote:
On 9/10/14, 8:42 AM, Sam Wilson wrote:
And you could reduce maintenance very slightly by replacing
www in A 75.100.245.133
with
www
even use a CNAME as a PTR???
Eliezer
On 09/11/2014 12:37 AM, Kevin Darcy wrote:
Also, have you considered the forward/reverse ambiguity that arises when
multiple owner names resolve to the same address? To which of those
names does the PTR point?
- Kevin
Based on the zone contents below, you shouldn't have any problem
changing the 192.168.1.100 address to anything you want.
But, of course, the zone is illegal because it only has 1 NS record
published at the apex (there is a strict minimum of at least 2), and, as
it stands now, if it is an
So you care enough about security to implement DNSSEC, but you run your
forwarder on port 80. Interesting...
- Kevin
On 8/26/2014 8:19 AM, Tomas Hozza wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello.
I found out that
On 7/31/2014 11:56 AM, Reindl Harald wrote:
Am 31.07.2014 um 17:41 schrieb /dev/rob0:
On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote:
i am doing reloads of named with killall -HUP named just because
i disabled rndc completly for security reasons and configurations
are generated
On 7/31/2014 3:08 PM, /dev/rob0 wrote:
On Thu, Jul 31, 2014 at 05:56:08PM +0200, Reindl Harald wrote:
Am 31.07.2014 um 17:41 schrieb /dev/rob0:
On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote:
i am doing reloads of named with killall -HUP named just
because i disabled rndc
I know of no way to do this within BIND itself, but if you Anycast your
nameservers, and carefully tweak route preferences and whatnot, you
could ensure that some instances (call it set A) only get used if all of
the members of another set of instances (call it set B) stop advertising
the
http://www.kitterman.com/spf/validate.html
- Kevin
On 7/8/2014 12:43 PM, Alex wrote:
Hi,
I have a mail server that manages mail for about ten domains, using
bind-9.9.4-12.P2 on fedora20. I'd like to make sure my SPF record in
my SOA is set up correctly,
...@lists.isc.org,
Kevin Darcy k...@chrysler.com wrote:
That scenario still shouldn't have led to an NXDOMAIN. If none of the
delegated nameservers are responding, you'd get a timeout or SERVFAIL.
So I think there's still some investigation to be done. But using dig
instead of nslookup at least makes
-rad.com
Bio-Rad Corporate IT - Desk: (510) 741-6846 Mobile: (510) 224-4343
On Mon, Jun 9, 2014 at 2:32 PM, Kevin Darcy k...@chrysler.com
mailto:k...@chrysler.com wrote:
Well, you shouldn't be getting an NXDOMAIN just because some of
your auth servers are off-line, but you could get
On 6/6/2014 7:35 AM, Reindl Harald wrote:
Am 06.06.2014 13:28, schrieb Matus UHLAR - fantomas:
On 06.06.14 13:13, Reindl Harald wrote:
why does in case of asking the slave always come a
WARNING: recursion requested but not available
even if you dig a A-record he is authoritative?
because you
On 6/5/2014 10:34 AM, Mike Hoskins (michoski) wrote:
-Original Message-
From: Nicholas F Miller nicholas.mil...@colorado.edu
Date: Thursday, June 5, 2014 at 10:25 AM
To: bind-users@lists.isc.org bind-users@lists.isc.org
Subject: SPF RR type
Are SPF RR types finally dead or not? I¹ve
The typical use case for a stub zone is where the delegation chain is
broken, or incorrect, but you don't want to incur the overhead of
slaving the zone (or some other sort of bureaucratic snafu like the
owner/admin of the zone not letting you do zone transfers).
As a general rule, stub zones
Why the different RCODES? See RFC 2308. Short version: the NODATA
response occurs when the QNAME exists, but no records match QTYPE. It
will also occur if the QNAME is merely a branch to something further
down in the hierarchy (a so-called empty non-terminal), and owns no
records of its own.
queries are non-recursive and we expect
the name server should have answers. We are sending test host with
very high query rate so BIND may be too busy to respond to all the
queries.
On Monday, May 19, 2014 4:25 PM, Kevin Darcy k...@chrysler.com wrote:
If a client sends a recursive query
If a client sends a recursive query to the BIND instance, and that
instance needs to fetch the answer from one or more other upstream
sources, then my understanding is that the resolver-query-timeout
global option (see the BIND docs) controls the timeout for each one of
those upstream
On 5/10/2014 3:00 AM, Mimiko wrote:
Hello.
I know there are WEB GUIs for bind, which uses a DB to store its
information and need read/write access to bind's config files and
zones files. Is there a GUI utility which will user zone transfers
with keys and dynamic updates?
In windows I
On 5/9/2014 6:59 AM, Tony Finch wrote:
Dave Warren da...@hireahit.com wrote:
On 2014-05-08 15:09, Mark Andrews wrote:
But that does not help when you want a MX record at the apex or
some other record at the apex.
I'd argue that it does -- Since the record is now CNAME'd, the MX record is
now
On 5/9/2014 3:01 PM, John Wobus wrote:
...if anyone has specific
thoughts on how to make this sort of thing easier in BIND -- even
just at
the level of boy, it irritates me that I can't make BIND do X --
such comments will fall on welcoming ears.
I agree that it would be nice if effort were
On 5/8/2014 5:13 PM, John Levine wrote:
DNSMadeEasy calls this an ANAME record, internally they just lookup
the destination's IP and cache it, updating it as needed.
It works, but it would be nice if this could be done in DNS. Sadly, it
can't, and probably won't in our lifetimes.
I do a
The apex name of a zone can't own a CNAME, if that's what you're asking.
E.g. the name example.com can't be a CNAME pointing at
otherexample.com.
But, of course, you can certainly put A and/or records at the apex,
that resolve to one or more addresses in one or more ranges you don't
Forwarder selection has been based on RTTs for quite a while now. So, if
what you're trying to protect against is your primary forwarders being
DoS'ed, why not just define your primary and backup forwarders in
the same forwarder list? Due to RTT calculations, the backup
forwarders would
Being authoritative means that you know everything about the zone.
If you know everything about a zone, why ask anyone else?
Split DNS does not follow the DNS paradigm, so there is no standard
way to implement it, and despite many people asking over the years,
there is no NXDOMAIN failover
Oh, I thought this was an external-versus-internal scenario. But, this
is even easier.
A) One of the nameservers (pick DNS1 or DNS2) becomes a slave (of the
stealth variety, if you want) of the other
B) People use nsupdate to maintain the zone
For security, TSIG-sign the updates. For fast
.
Thanks again
On Wed, Apr 30, 2014 at 5:54 PM, Kevin Darcy k...@chrysler.com
mailto:k...@chrysler.com wrote:
Oh, I thought this was an external-versus-internal scenario. But,
this is even easier.
A) One of the nameservers (pick DNS1 or DNS2) becomes a slave (of
the stealth
On 4/29/2014 3:12 PM, Roberto Carna wrote:
Dear, I have this scenario:
1) Windows DNS with dynamic update zone (Windows clients)
2) BIND with manually update zone (Linux and Cisco clients)
Is there any way to transfer all BIND zone records to the Windows DNS
in order to have just one and
I'm not sure this makes sense from an architectural standpoint. If all
of the authoritative NSes are down, where is this backup nameserver
getting its data from, and how current is that data?
If slightly *stale* data is acceptable, in the absence of all
authoritative NSes, then why not just
Are you running *other*, non-network-service functions on these boxes
besides BIND/MM? If not, then you might find an appliance-based
solution like Bluecat or Infoblox might be more cost-effective than
adding a DNS-management layer to a generic server. Your security folks
should love you too,
.
Thanks,
Josh
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kevin Darcy
Sent: Monday, April 28, 2014 12:50 PM
To: bind-users@lists.isc.org
Subject: Re: Enterprise IPAM/DNS Solutions
Are you running *other*, non-network
allow-update + manual editing of zone file = bad.
Use nsupdate.
- Kevin
On 4/25/2014 4:03 PM, Jeronimo L. Cabral wrote:
Dear, I'm using Bind 9.8.4 with a master / slave scenario. Zone
transfer works OK when I have this config in named.conf.local from
master server, add some A records and
On 4/14/2014 2:58 PM, Steven Carr wrote:
On 14 April 2014 18:53, Felix Rubio Dalmau felixrubiodal...@gmail.com wrote:
it is not actually a pure caching server (at least I didn't wanted it
to be :S). I have server at home, and the DNS is properly configured at the
internet. The
What isn't clear so far is whether the TXT record you're looking up is
in the myserver.org zone or some other zone.
If you're authoritative for myserver.org, you're authoritative for *all*
of myserver.org. named isn't going to do failover forwarding just
because you neglected to add a TXT
Regardless of what you've been told, the resolvers (nameservers) in
/etc/resolv.conf are tried *in*sequence*, and if a valid response (where
NXDOMAIN _is_ a valid response) is received from one resolver, none of
the others are tried. So, I'm surprised that your
mix-and-match-resolvers hack
I'm assuming you have forwarding set up. Make sure to set forwarders {
}; in the aelabad.net zone definition. Failure to do so means that your
recursive queries for names in subzones forward out towards the
Internet, instead of following the delegations down to the
austin-energy.net
On 3/25/2014 9:01 AM, Ian Braun wrote:
Hello,
We have a bind server (v9.6) that's hosts mydomain.com
http://mydomain.com. I'm trying to create a CNAME for
host.mydomain.com http://host.mydomain.com to point to
host.otherdomain.com http://host.otherdomain.com. I don't host
otherdomain.com
On 3/21/2014 9:03 AM, Casey Deccio wrote:
On Fri, Mar 21, 2014 at 8:50 AM, Mitchell Kuch mi...@basejp.com
mailto:mi...@basejp.com wrote:
Hello -
I've adopted a number of zones and most of them contain localhost in
a 127.0.0.1 records. I'm curious what current RFC standards state
On 3/15/2014 6:09 AM, Maren S. Leizaola wrote:
On 3/15/2014 1:53 AM, Kevin Darcy wrote:
On 3/14/2014 8:28 AM, Maren S. Leizaola wrote:
Hello,
What do you guys recommend to audit every resource
record in a zone file against all the records in all the DNS servers
that host
On 3/14/2014 8:28 AM, Maren S. Leizaola wrote:
Hello,
What do you guys recommend to audit every resource
record in a zone file against all the records in all the DNS servers
that host the zone file.
I want something that I feed the master zone file and then goes to each
NS
On 3/14/2014 2:39 PM, Maren S. Leizaola wrote:
On 3/14/2014 9:20 PM, Stephane Bortzmeyer wrote:
On Fri, Mar 14, 2014 at 12:33:47PM +,
Phil Mayers p.may...@imperial.ac.uk wrote
a message of 25 lines which said:
dig @server zone axfr file
diff file file.real
If you're really paranoid,
for a school project.
Regards, Peter
On 12/03/14 19:56, Kevin Darcy wrote:
First of all, don't use .loc as an internal TLD. There are *many*
proposals in process with ICANN for establishing new TLDs, and for all
you know, .loc might be one of them. If .loc gets established on the
Internet
First of all, don't use .loc as an internal TLD. There are *many*
proposals in process with ICANN for establishing new TLDs, and for all
you know, .loc might be one of them. If .loc gets established on the
Internet, and you're using it internally, that presents abundant
opportunities for
Options:
1) Change nameservice-switch order (e.g. /etc/nsswitch.conf) on your
hosts to prefer another source of name resolution (e.g. /etc/hosts)
which can resolve the shortname. Thus DNS is never used for these lookups
2) Simply :-) change your DNS architecture fundamentally, from one which
On 3/10/2014 6:05 PM, Andreas Ntaflos wrote:
On 2014-03-10 22:23, Kevin Darcy wrote:
Options:
First, thanks a lot for the reply! So it seems what I described is
indeed the expected behaviour for the type of DNS we operate?
1) Change nameservice-switch order (e.g. /etc/nsswitch.conf
!
Guanghua
Date: Mon, 24 Feb 2014 13:41:03 -0500
From: Kevin Darcy k...@chrysler.com
To: bind-users@lists.isc.org
Subject: Re: how to hidden the salve
Message-ID: 530b923f.8070...@chrysler.com
Content-Type: text/plain; charset=iso-8859-1; Format=flowed
I guess I'm still not understanding your
?
For the
'stealth' slave isn't in the NS records.
Also-notify directive. Either in an options stanza or a zone stanza.
thanks,
Guanghua
--
Daniel J McDonald, CISSP # 78281
Date: Thu, 20 Feb 2014 10:48:36 -0500
From: Kevin Darcy k...@chrysler.com
To: bind-users@lists.isc.org
Subject: Re: how
servers in the NS records are out of service
( maybe in case of ddos attack).
Guanghua
--
On 2/19/2014 11:54 AM, Kevin wrote:
Date: Wed, 19 Feb 2014 11:54:44 -0500
From: Kevin Darcy k...@chrysler.com
To: bind-users@lists.isc.org
Subject: Re: how to modify the cache
Not a good solution. Even under normal circumstances, there will be
temporary bottlenecks, dropped packets, etc.. that will trigger failover
and users will get different answers at different times. Not good for
support, maintainability, user experience/satisfaction, etc.
If all you want is
...
- Kevin
On 2/17/2014 5:44 PM, Doug Barton wrote:
On 02/17/2014 11:37 AM, Kevin Darcy wrote:
Ugh, that mixes apples (recursive resolution) and oranges (iterative
resolution).
Out of curiosity, what bad thing do you think will happen if you mix
these two
/17/2014 5:56 PM, Kevin Darcy wrote:
Bad performance, bad reliability, clandestine IP-over-DNS tunnels
between networks that are supposed to be isolated...
Is that enough?
Understanding the pros and cons of iterative versus recursive
resolution is one of the few things still separating us from
Indeed. Regular stub only overrides the parent's delegation NS
records; static-stub overrides the apex NS records of the zone as
well. My uses of the words stub (which I intended to cover both forms
of stubbing) and published (which I intended to cover both the
delegating and apex records)
1 - 100 of 491 matches
Mail list logo
