RFC 1918 forbade the publishing of private addresses outside of the enterprise:
"Indirect references to [private] addresses should be contained within the
enterprise. Prominent examples of such references are DNS Resource
Records and other information referring to internal private
addresses. In
ant Taylor
via bind-users
Sent: Wednesday, June 27, 2018 11:04 PM
Cc: bind-users@lists.isc.org
Subject: Re: Domain name based multihome routing?
On Jun 27, 2018, at 12:27 PM, Darcy Kevin (FCA)
wrote:
> I’m not convinced DNS has any valuable role to play here.
I can see the value for s
IANAL, but even if one considers this scenario to constitute a DDoS attack, and
there is plenty of case law supporting prosecution under CFAA (Computer Fraud
and Abuse Act) for DDoS attacks, CFAA generally requires *intent*, and this
appears to be simple negligence.
"Trespass to chattel" might
Domain Controllers certainly need to have their hostnames registered in the AD
domain, but regular domain-joined members do *not*. We've been running AD for
decades, without registering members in the AD domain. Works fine. Instead, we
get our (non-Microsoft) DHCP servers to register dynamic
, 2018 2:18 PM
To: Darcy Kevin (FCA)
Cc: bind-users@lists.isc.org
Subject: Re: Domain name based multihome routing?
On Wed, Jun 27, 2018 at 12:27 PM, Darcy Kevin (FCA)
mailto:kevin.da...@fcagroup.com>> wrote:
I’m not convinced DNS has any valuable role to play here. Seems like this is a
t
I’m not convinced DNS has any valuable role to play here. Seems like this is a
traffic-shaping challenge; maybe one of the open source traffic shaping tools
would fit the bill.
“We are aware that we should not mix the plain text configuration with these
dynamic records (and use a subdomain instead)”
So, why don’t you do that? As far as I know, Domain Controllers still only
maintain SRV records, so the “underscore zones” approach should still work.
Make
On a case-by-case basis, one can use stub zones, conditional forwarding, etc.
but if you're looking for a "break Internet standards" switch, I think you're
going to be disappointed. Vix has stopped calling BIND a "reference"
implementation of DNS, but it still tries to set a good example.
"Stealth" implies something that isn't seen in the normal course of activity,
so it's really the *wrong* word to use here, since the apex NS records are seen
during normal iterative resolution, and in fact the apex NS records take
precedence over the delegated NS records in the sense of RFC
Why are you letting the clients register their own addresses in DNS in the
first place? If you want a higher level of control, move the DDNS
responsibility to the DHCP server.
We're getting a little afar of DNS and BIND here, since this is OS networking
configuration stuff, made slightly more complicated by the fact that (as far as
I can see) you didn't specific what OS and/or distro you're running.
So let's get generic.
Google'ing "pppd override resolvers". First
Call me a contrarian, but I've never really signed onto the conventional wisdom
that recursive and authoritative roles should never be mixed, even as I've
transitioned into the InfoSec realm, where, generally speaking, we are quite
wary of mixing roles within a single service (more software
You mean, don't slave 100.10.in-addr.arpa at all, and just maintain
10.in-addr.arpa locally?
The problem the original poster may run into, however, is that there may be
other records in 100.10.in-addr.arpa that change dynamically, and those changes
may not be reflected if only 10.in-addr.arpa
Are you asking about the search algorithm in *DNS* (hierarchical, labelwise
exact match, with aliasing and wildcarding special cases), or the algorithm by
which *BIND* -- as one *implementation* of DNS -- accesses data in its internal
structures (modified red-black tree, IIRC)?
You can certainly configure the subdomains that way, but the same resolver
which followed the subdomain.example.com delegation in the first place, to your
BIND instance, will presumably follow the delegation of
sub.subdomain.example.com (as it is published via NS records in the parent
zone) to
But surely you’d get an NXDOMAIN in that case, not a SERVFAIL.
The assumption I made in my post was that the delegation was pointed to the
forwarding BIND instance, which is a non-starter.
- Kevin
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ben
Croswell
It doesn't work to delegate to a forwarder; you have to delegate to something
that's authoritative for the zone (master or slave). Delegated nameservers are
expected to have a full copy of the zone, either as the source (master) or
through replication (slave).
Now, if you have
For this reason, "stub" resolvers typically set RD=1, and only "full-service
resolvers", such as the one integrated into named (although there are
standalone ones, like Knot, Unbound, [1]), generate RD=0 queries. Full-service
resolvers are capable of taking the referrals, and using them to
Well, it's not *obvious* how Dynamic Update works in the case of an SOA RR, but
RFC 2136 does say:
3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
the zone. In case of duplicate RDATAs (which for SOA RRs is always
the case, and for WKS RRs is the case if the ADDRESS
Just as a general piece of advice, if you're trying to troubleshoot a zonefile
parsing issue, sometimes it's useful to just do a zone transfer of the loaded
zone and eyeball it. This is obviously more practical with a smaller zone (such
as the one you showed) than a huge one, but even if the
Appending suffixes to short names to make them legal DNS names, is considered
the responsibility of the *client*, not the *server*.
Look up “resolver search list” (more Unix-ish/Linux-ish) or “suffix search
list” (more Windows-ish), and you should find some useful information.
-
-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Reindl
Harald
Sent: Wednesday, August 09, 2017 6:48 PM
To: bind-users@lists.isc.org
Subject: Re: bind-chroot, runs, works, dies
Am 10.08.2017 um 00:35 schrieb Darcy Kevin (FCA):
> I’m not very familiar with Fedora, but on Redhat, at le
I’m not very familiar with Fedora, but on Redhat, at least, there is no /run
directory. Which makes me think that “/var/named/chroot/run/named/named.pid” is
a misconfiguration. That would be seen as “/run/named/named.pid” from *within*
the chroot. Following usual conventions, I think you
The bottom line is that a *zone* is the basic administrative unit of
AXFR/IXFR-based replication. If you create a new zone and you want a replica to
serve it, you need to configure the replica to replicate it. There is no
"automatic" mechanism within BIND to tell replicas to start slaving new
You have a trailing dot in the zone definition. It makes a difference.
Personally, I wouldn't use forwarding at all, and I'd build this for
scalability. Define a master zone for, say, 168.136.dnssd.presto, and then
delegate from that to whatever address ranges you deploy Presto to in the
BIND has no way of differentiating these queries, since reverse-lookup queries
aren't "special".
But certainly, if you syslog rather than writing directly to a file, there are
syslog daemons that can filter, based on regex'es and the like.
In the grand tradition of _ceci_n'est_pas_une_pipe_, how dig *represents* a
piece of TXT contents isn't necessarily how it *is*.
I just verified (via tcpdump) that a TXT record label that shows up as "blah\\"
in dig's (and host's) output, actually only contains a single backslash (hex
code
As far as I know, the only "special" thing that BIND does consistently on a
restart, that it doesn't do on a regular basis in normal operation, is a
"priming" query to whatever is configured as root nameservers. I suppose it's
_possible_ that there is something about priming queries,
As others have commented, more information about your config and your setup
need to be provided, before a proper troubleshooting can occur. I would add,
you should be more specific than just “resolution error”. Is it a timeout? An
NXDOMAIN? A SERVFAIL? A so-called “NODATA” response or a
, even under
transitive closure of the internal network? It's surely a proper subset of all
instances of BIND, but I doubt if it's other than a quite small subset.
On Tue, 18 Apr 2017 17:22:24 +
"Darcy Kevin (FCA)" <kevin.da...@fcagroup.com> wrote:
> Unspoken and false ass
Unspoken and false assumption: that every machine running BIND is connected to
the Internet.
I'm no fan of old, broken Microsoft OSes (or even the newer ones, for that
matter), but let's be clear here: BIND is for anyone who doesn't want to
maintain a "hosts" file. "Connected to the Internet"
Honestly, this is like asking for a closet that automatically throws out the
items you pitch into it, once the items are deemed obsolete or junk.
The DNS database is a repository of information, like a closet, but it has no
inherent way of knowing the value or currency of the information that
I think the ISP may have done something untoward with
87.233.202.162.in-addr.arpa, since I'm getting a NODATA response for that name,
from the 233.202.162.in-addr.arpa zone, most probably because it's an empty
non-terminal. But what would be under that, and why?
Seems like your requirements call for the classic, old-school "internal root"
setup. Define your own root zone that *only* has delegations for example.com
and whatever parts of the in-addr.arpa namespace you want to resolve. That way,
everything outside the example.com namespace and the
Well, I suppose it's a little silly that the informational message would count
"none" as an "IP address", but on the other hand, why specify "allow-update {
none; };" when that's the default? It probably never occurred to the
creator/author of the informational message that someone would
Same here. Slave the AD zones, all end-user machines use BIND-based (Infoblox)
servers for resolution, on Anycast addresses. DHCP servers (also Infoblox)
update DNS for the clients, with the client names being registered in non-AD
zones (some of which are defined by geography, with a generic
Correct, wildcards don't work that way; in fact, it would be more accurate to
say that _vlmcs._tcp.*.foo. isn't a wildcard at all (it's just a DNS name that
happens to have an asterisk as one of its labels). See RFC 4592.
- Kevin
Ideally, whatever frontend you use to maintain the "forward" records for these
zones, should be smart enough to, in parallel, populate the corresponding
entries in the common reverse zone.
But, failing that, it shouldn't be that hard to write a script that
periodically pulls zone transfers of
-
From: Darcy Kevin (FCA)
Sent: Monday, October 17, 2016 3:11 PM
To: bind-users@lists.isc.org
Subject: RE: defines ip to acl
Well, things are messy, because you haven't carved up your subnet on
bit-boundaries. BIND ACLs are either individual IPs, CIDR blocks, negations, or
some combination
Well, things are messy, because you haven't carved up your subnet on
bit-boundaries. BIND ACLs are either individual IPs, CIDR blocks, negations, or
some combination of these. It can be done:
192.168.1.1 through 192.168.1.99 = !192.168.1.0; 192.168.1.0/26;
192.168.1.64/27; 192.168.1.96/30;
To be clear, the zone is defined in named.conf -- otherwise the original poster
would have never said that "allow-update" was configured for the zone -- but
there is something wrong with the configuration, or in the zone file itself,
that is preventing it from being properly loaded and served.
There's nothing particularly unusual about the "retrying in TCP mode" message -
as Mark explained, that happens whenever the packet size is big and EDNS0 is
not being used.
I looked up this name from an internal Windows 7 box through a BIND-based
forwarder (in North America), and it resolves
Yeah, sure, just run it with your own special config file (with -c); in that
config file, set the listen-on to an unprivileged port, and make sure all of
the pathnames (including implicit pathnames like the pid-file) are to
files/directories to which the unprivileged user has read and (where
Are you sure that's what you want? In a different thread, you said you had a
second LAN besides 192.168.1.0/24; you called it "LAN2", and further described
it as being "DHCP only". That second LAN was identified by you as
192.168.10.0/24.
I'm thinking you meant to define the second zone as
.
- Kevin
-Original Message-
From: Pol Hallen [mailto:bin...@fuckaround.org]
Sent: Monday, September 19, 2016 6:14 PM
To: Darcy Kevin (FCA); bind-users@lists.isc.org
Subject: Re: about
In the first case, your resolver probably had to resolve all levels of the
hierarchy from the root all of the way down to the leaf node (root, .it,
yahoo.it and then the leaf records). 96 msec.
In the second case, the answer was cached and so your resolver didn't have to
talk to anything on
That's not a valid IPv6 address representation. You probably mistyped a double
colon as a single colon in the middle of the address.
(RFC 4291)
2.2. Text Representation of Addresses
There are three conventional forms for representing IPv6 addresses as
text strings:
1. The preferred
AXFR over UDP is explicitly undefined. See RFC 5936 Section 4.2. Given this, I
would have expected either a FORMERR response (interpreting the request itself
as "illegal"), or a NOTIMPL response (interpreting "undefined" as "might have
been defined by an RFC subsequent to 5936, but I don't
>From an InfoSec standpoint, of course one would prefer to use cryptographic
>methods of securing DNS data, but, in the absence of that, slaving could,
>arguably, be considered more secure than forwarding, in the sense that
>forwarding usually generates more network transactions, over time, for
Look in your logs at the time of named startup to see if your root-server
priming failed at that time.
- kevin
-Original Message-
From: bind-users
Or just check the RFCs.
https://www.ietf.org/rfc/rfc5452.txt
- Kevin
-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mukund
Sivaraman
Sent: Friday, August 19, 2016 2:27 AM
To: pm8...@t-online.de
Cc:
Well, the cost/benefits/risks of separating authoritative and recursive on
different *servers* (as opposed to different NICs, views, or whatever) is
actually a hotly-debated topic among experts. I know some non-DNS-expert
opinions, from the InfoSec side of the house, consider hardware-level
e <mailman.301.1471466524.15653.bind-us...@lists.isc.org>,
"Darcy Kevin (FCA)" <kevin.da...@fcagroup.com> wrote:
> Barry,
> Cloudflare has been doing this for a while, so that their customers
> won't be "limited by the DNS specifications (RFCs)" .
>
---
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Barry
Margolin
Sent: Wednesday, August 17, 2016 4:34 PM
To: comp-protocols-dns-b...@isc.org
Subject: Re: Selective forwarding from an internal only name server
In article <mailman.299.1471461214.15653.bind-us...@lists.
Well, sharepoint.com is a CNAME to sharepoint.microsoft.com, so you might need
to make arrangements for that to be resolvable as well.
Forwarding is a different beast from "stub" (recursive rather than iterative
resolution).
I'd look at "static-stub", if your NS list is overgrown with
useless/unreachable stuff. It's configured basically the same way as
forwarding, but without making the paradigm shift (and possible unforeseen
True, strictly from a per-hop latency standpoint, there shouldn't be much
difference between forwarding a packet or forwarding a DNS query.
Having said that -- and I'm sure the BIND developers could elaborate further on
this -- I know that there's big difference between processing *packets*,
environment.
In any case, multi-hop forwarding is always the least-preferred option.
- Kevin
From: Darcy Kevin (FCA)
Sent: Thursday
No, you would never get rid of a valid delegation of a child zone; why *reduce*
the resolvability of that zone? Whatever you do to get around this connectivity
issue would be *in*addition*to* the delegation, not as a replacement for it.
That having been said, I outlined your options in a
The bottom line is: any resolver which is using iterative resolution (as
opposed to just forwarding) to resolve names in a zone, needs to be able to
talk to at least *some* of the published nameservers for the zone, or to
“override” the regular referral-chain using something like a “stub” zone.
As already noted, allow-query will cause you to send back a REFUSED response.
That’s sort of the whole point of the REFUSED RCODE.
If you want to not send back any response *whatsoever*, then take a look at the
“blackhole” statement, but, honestly, this kind of “drop” function may,
depending
a point of equilibrium.
- Kevin
-Original Message-
From: Mark Andrews [mailto:ma...@isc.org]
Sent: Thursday, August 04, 2016 7:47 PM
To: Darcy Kevin (FCA)
Cc: bind-users
:32 PM
To: Darcy Kevin (FCA); bind-users@lists.isc.org
Subject: Re: change response cache ttl (--enable-cache-ttl)
Am 04.08.2016 um 20:27 schrieb Darcy Kevin (FCA):
> "many client have caused a burst DNS traffic" is not much of a problem
> statement, honestly.
>
> Wh
"many client have caused a burst DNS traffic" is not much of a problem
statement, honestly.
What does this patch add, of value, that isn't already covered by
"max-cache-ttl"?
If you're trying to allow the operators of intermediate resolvers to override
the intentions of the data owner, by
Most likely, it has to do with recursion settings, yes, but indirectly. When
recursion is not honored for a client, the next thing that named does is check
whether the answer, or anything relevant to the answer, is in cache. But access
to the cache, these days, defaults to being as restrictive
nslookup sucks.
What’s most likely happening is:
· On your initial query, some sort of transient error is occurring
while trying to resolve centos.mirror.iweb.ca, e.g. a timeout, a misconfigured
server returning SERVFAIL, a delegated server not being authoritative, etc.
·
Is it really necessary to document everything that *isn't* true? That could
fill volumes...
named is the thing that resolves stuff; /etc/resolv.conf tells processes whom
to talk to if they want to resolve stuff. Put those things together, why would
named need /etc/resolv.conf? To talk to
Darcy
NAFTA Information Security Projects
FCA US LLC
1075 W Entrance Dr,
Auburn Hills, MI 48326
USA
Telephone: +1 (248) 838-6601
Mobile: +1 (810) 397-0103
Email: kevin.da...@fcagroup.com
From: Vinícius Ferrão [mailto:fer...@if.ufrj.br]
Sent: Thursday, July 28, 2016 10:03 AM
To: Darcy Kevin (FCA
, July 28, 2016 12:52 PM
To: Darcy Kevin (FCA)
Cc: bind-users@lists.isc.org
Subject: Re: Multiple AD domains
The OP's question was about setting up BIND, not MS DNS, related to using
Samba, not Windows, as the domain controller.
Regards,
Chris
Sent from my iPhone
On Jul 27, 2016, at 12:36 PM, Darcy
My preference? Have all your clients use BIND to resolve DNS (this gives access
to more advanced features like sortlisting, good query logging,
blacklisting/redirection through the RPZ mechanism, Anycast, etc.). Set up the
BIND instances as slaves for the AD zones, and have the AD folks add the
Sachin,
I strongly suggest that you consider other methods to
accomplish what you’re trying to achieve. You seem to have latched onto one
particular method to reach your goal – modifying the contents of the DNS
request and/or response packets – but this amounts to changing the
I think what the kids would say is "client PCAP or it didn't happen".
Now, get off my lawn... :-)
- Kevin
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of John W. Blue
Sent: Thursday, June 16, 2016
quot; responses like that?
- Kevin
-Original Message-
From: Tony Finch [mailto:d...@dotat.at]
Sent: Thursday, June 16, 2016 7:09 AM
To: Darcy Kevin (FCA)
Cc: bind-users@lists.isc.org
Subject: RE: Append a Hard-coded Text Tuple into Additional Section of "dig"
Feature
Darcy Kevin (
That's not really consistent with the DNS standards, and will break if you have
intermediate caching servers. Why? Because of this clause from RFC 2181:
Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and
data
Margolin
Sent: Monday, May 02, 2016 5:08 PM
To: comp-protocols-dns-b...@isc.org
Subject: Re: also-notify and nsupdate doesnt work
In article <mailman.688.1462221733.73610.bind-us...@lists.isc.org>,
"Darcy Kevin (FCA)" <kevin.da...@fcagroup.com> wrote:
> Apologies if th
Apologies if this has already been asked, but are you sending these NOTIFYs
from a master which is _not_ in the "masters" clause of the nameserver which is
receiving it? That's precisely the use case for "allow-notify"...
-
, i found some error info about
( ipv6)
In article <mailman.548.1460561615.73610.bind-us...@lists.isc.org>,
"Darcy Kevin (FCA)" <kevin.da...@fcagroup.com> wrote:
> Really, there's no excuse, in this day and age, for a DNS-serving
> device -- even a load-balancer
To be clear, "turning off" IPv6 in named (via the -4 flag or other means),
doesn't mean named won't try to resolve any records, especially if one of
your (presumably IPv6-enabled) clients requests them. So, even with IPv6
"turned off", if there are nameservers on the Internet that -- for
This is deliberately forbidden by standard. See RFC 2181, Section 5.2 ("TTLs of
RRs in an RRSet")
Why would you want to do this?
- Kevin
From: bind-users-boun...@lists.isc.org
Would they be receptive to letting you slave the zone? At least then you’d have
the whole EXPIRE time before the names stopped resolving.
If they’re concerned about security, then the transfers could be locked down by
source IP address, or, if their software supports it, TSIG key.
One of the
By “upstream” I assume you’re talking about forwarders. If your forwarders are
flakey, have you ever considered simply *not*forwarding*? That would seem to be
a better, structural solution to your problem, than holding DNS data beyond its
cache-expiration time (a really BAD idea).
.
- Kevin
From: Ron [mailto:ron.a...@gmail.com]
Sent: Thursday, March 17, 2016 11:46 AM
To: Darcy Kevin (FCA)
Cc: bind-users@lists.isc.org
18, 2016 4:41 PM
To: bind-users@lists.isc.org
Subject: Re: Can bind be configured to not drop RR's from the cache when the
upstream DNS server is unresponsive
Slave the zone? Oh, run secondary. Fat chance.
Ron
On Fri, Mar 18, 2016 at 5:03 PM, Darcy Kevin (FCA)
<kevin.da...@fcagroup.
Don't turn your DNS and/or network infrastructures into pretzels trying to get
this "forwarding" or "(reverse) proxying" to work. Ultimately, I expect you'll
end up maintaining the records of interest in both an internal and an external
version of the subzone. Then the only question becomes to
I wouldn't be so quick to assume that.
Nota bene this part of the ARM:
"Integers may take values 0 <= value <= 18446744073709551615, though certain
parameters (such as max-journal-size) may use a more limited range within these
extremes. In most cases, setting a value to 0 does not literally
See “empty non-terminal” in https://www.rfc-editor.org/rfc/rfc4592.txt.
- Kevin
[FCA_Pantone_email]
--
Kevin Darcy
NAFTA
Let's be transparent here: reverse lookups are not a formal requirement, and,
if I'm not mistaken, not even officially published as a Best Practice. Many
folks don't bother with them.
Having said that, they are *very* useful, and I insist on them wherever
possible.
If an organization decides
Look at your "allow-query". It appears your master isn't letting your slave
query it. Query access is a prerequisite for zone-refresh transactions.
- Kevin
-Original Message-
From: bind-users-boun...@lists.isc.org
As pointed out previously, however, with a 1-minute REFRESH, NOTIFY is pretty
much a non-issue.
- Kevin
-Original Message-
From: Darcy Kevin (FCA)
Sent: Friday, February 19, 2016 4:25 PM
To: BIND Users
Subject: RE: A Zone Transfer Question
How
How do you suppose named knows where to send the NOTIFY messages? It's only
"automatic" to the nameservers listed in the NS records of the zone. But you
didn't list your slave, did you? I seem to recall there was only 1 NS record,
and that's presumably the master...
Guys,
REFRESH is set to 1 minute. That's not a long time to wait. Just do
a packet capture and see if the slave is issuing zone-refresh queries regularly
in the 30-second-to-1-minute range (it's randomized, of course, between
REFRESH/2 and full REFRESH).
If the slave isn't issuing
Ah, so "recursive-clients" is the quota of queries that require named to
recurse to get the answer, right? I was going to respond with the same advice
-- slave your internal zones -- but then I somehow convinced myself that
"recursive-clients" was merely the quota of concurrent RD=1 queries
Note that there are additional considerations if there are any descendant
(child, grandchild, etc.) zones of intra.example.net. If "type forward" is
specified in the intra.example.net zone definition, and nothing defined below
that, then recursive queries will continue to be sent, even for
I suspect they changed the algorithm, in light of recent research findings
about attackability. See
http://www.cs.technion.ac.il/~gnakibly/papers/WOOT13.pdf
Why not? Data obtained from the recursive function will never outrank
authoritative data of a master or a slave. See the "Data Ranking" section of
RFC 2181. AFAICT, it's been a *very* long time since BIND, or any other DNS
implementation, has accidentally got those ranking rules wrong and given
Suffix searching is a client function, there is no explicit support for it in
BIND or any nameserver implementation.
The only incredibly ugly thing you could do in DNS to support shortname
resolution is set up a "fake" root zone containing the names you need to
resolve. But, you really don't
NXDOMAIN is not a "failure" response. Are you *sure* you're getting NXDOMAIN?
If you're using nslookup to test, be aware that it will do suffix searching by
default, so if the original query, e.g. www.bbc.co.uk fails, it'll quietly
(unless debug-mode is in effect) start appending suffixes.
Well, when I queried the name livetileedge.dsx.mp.microsoft.com, I got a CNAME
chain where all of the links in the chain had TTLs of 300 seconds or less:
livetileedge.dsx.mp.microsoft.com. 43 IN CNAME
livetileedge.dsx.mp.microsoft.com.akadns.net.
livetileedge.dsx.mp.microsoft.com.akadns.net.
Well, the apex record of a zone can’t be an alias, and you can’t legally point
an MX record to an alias as its target. So I don’t know if you’ll get much
success, either way…
Can you move off the dynamic stuff to a subzone, e.g. dhcp.example.com? Then
the main zone could be static, and that
Addition of an MX record to a dynamically-updated zone can be accomplished
multiple ways, but I’d recommend using nsupdate.
Responding differently to “internal” versus “external” queries implies views.
But, the burning questions that need to be answered are:
1) do you need those DHCP-driven
1 - 100 of 141 matches
Mail list logo
