Cc: bind-users
Subject: Re: forwarding non-domain queries
ATTENTION: This email came from an external source. Do not open attachments or
click on links from unknown senders or unexpected emails.
Hi Brian.
I'm confused. In previous mails you confirmed that you had removed the hint
zo
own and
> restart, not just a reload.
> Get the messages about the extra NS “.” And unable to find root files,
> restored the stanza, same error.
>
>
>
> Thanks,
>
> Brian
>
>
>
> *From:* Greg Choules
> *Sent:* Thursday, February 6, 2025 3:18 AM
> *To:* Cutt
3:18 AM
To: Cuttler, Brian R (HEALTH)
Cc: bind-users
Subject: Re: forwarding non-domain queries
ATTENTION: This email came from an external source. Do not open attachments or
click on links from unknown senders or unexpected emails.
Hi Brian.
I'm confused. In previous mails you confirmed that
.net' in hints
>
> 05-Feb-2025 12:08:46.336 general: warning: checkhints: unable to find root
> NS 'm.root-servers.net' in hints
>
> 05-Feb-2025 12:08:46.336 general: warning: checkhints: extra NS '.' in
> hints
>
>
>
> I did put in place th
25 12:08:46.336 general: warning: checkhints: extra NS '.' in hints
I did put in place the forward records, pointing to the two primary NYS
internal servers so we should be using that rather than the root servers or the
domain servers.
I do still have in place some more specific for
Greg,
From: Greg Choules
Sent: Wednesday, December 18, 2024 5:04 PM
To: Cuttler, Brian R (HEALTH)
Cc: bind-users
Subject: Re: forwarding non-domain queries
ATTENTION: This email came from an external source. Do not open attachments or
click on links from unknown senders or unexpected emails
ouldn't get address for 'd.edu-servers.net': failure
>
> couldn't get address for 'e.edu-servers.net': failure
>
> couldn't get address for 'f.edu-servers.net': failure
>
> couldn't get address for 'g.edu-servers.net': failure
rs.net': failure
couldn't get address for 'l.edu-servers.net': failure
couldn't get address for 'm.edu-servers.net': failure
dig: couldn't get address for 'a.edu-servers.net': no more
From: Cuttler, Brian R (HEALTH)
Sent: Tuesday, December 10, 2024
;
> Brian
>
>
>
> *From:* Greg Choules
> *Sent:* Tuesday, December 10, 2024 9:54 AM
> *To:* Cuttler, Brian R (HEALTH)
> *Cc:* bind-users
> *Subject:* Re: forwarding non-domain queries
>
>
>
> *ATTENTION: This email came from an external source. Do not open
>
From: Greg Choules
Sent: Tuesday, December 10, 2024 9:54 AM
To: Cuttler, Brian R (HEALTH)
Cc: bind-users
Subject: Re: forwarding non-domain queries
ATTENTION: This email came from an external source. Do not open attachments or
click on links from unknown senders or unexpected emails.
And my
c zones in the internal corp
> network.
>
>
>
> brian@cedar:/etc/dns-root$ more db.cache
>
>
>
> @ IN A 10.108.43.7
>
> @ IN A 10.108.43.8
>
>
>
> @ IN NS @
>
>
>
> *From:* Greg Choules
> *Sent:* Tuesday, December 10, 2024 9:38 AM
>
cedar:/etc/dns-root$ more db.cache
@ IN A 10.108.43.7
@ IN A 10.108.43.8
@ IN NS @
From: Greg Choules
Sent: Tuesday, December 10, 2024 9:38 AM
To: Cuttler, Brian R (HEALTH)
Cc: bind-users
Subject: Re: forwarding non-domain queries
ATTENTION: This email came from an external source. Do not
Hi Brian.
So in your config you still have a section like this?
zone ".: {
type hint;
file ;
};
You don't need it a) at all anyway, for the reason I gave and b) because
you are forwarding everything non-local and if you specify "forward only;"
for both global for
lf Of Greg Choules
via bind-users
Sent: Tuesday, December 10, 2024 2:57 AM
To: Nick Tait
Cc: bind-users@lists.isc.org
Subject: Re: forwarding non-domain queries
ATTENTION: This email came from an external source. Do not open attachments or
click on links from unknown senders or unexpected emails
: forwarding non-domain queries
ATTENTION: This email came from an external source. Do not open attachments or
click on links from unknown senders or unexpected emails.
Hi Brian.
If that's what you want to do; answer authoritatively from local zones you own
and forward everything else to Corp
Hi Nick.
True, they do, but very infrequently. Here are the ones I could find from
recent history:
b-root 2023-11-27
i-root 2016-03-23
h-root 2015-12-01
d-root 2013-01-03
l-root 2007-11-01
Despite those changes, each release of BIND (and other resolvers, I
believe) contains the current set, whatev
On 10/12/2024 12:25, Greg Choules via bind-users wrote:
Actually you don't need it anyway, even if you are doing recursion, as
Internet root hints have been built into BIND for many years. The only
reason you would need a hint zone is to define custom roots for a
private network that is *comple
Hi Brian.
If that's what you want to do; answer authoritatively from local zones you
own and forward everything else to Corporate, then you have it correct.
"forwarders {...etc" and "forward only;" go in the "options" block.
Since you are forwarding everythi
Hello, looking for a sanity check.
Inside our network we are running BIND 9.18.28-0ubuntu0.22.04.1-Ubuntu on
Ubuntu 22.04.5 LTS
Currently our server serves our own zones files - A/CNAME/PTR/TXT/etc records
for our domain.
We have already modified the db.cache file to reference two servers prov
On 16.08.24 19:55, Tim Maestas wrote:
You need to have the delegation in the parent in order for the forwarding
to kick in. It can be bogus, but it has to be there. You'll find the same
behavior when you're authoritative for the root zone; any type forwarded
zones will need to also
You need to have the delegation in the parent in order for the forwarding
to kick in. It can be bogus, but it has to be there. You'll find the same
behavior when you're authoritative for the root zone; any type forwarded
zones will need to also have NS in the root ( or closest
Hello,
our customer has private .local zone "example.local"
(I know this should be used for multicast...)
so I have configured forwarding queries for this domain to his servers:
zone "example.local" {
type forward;
forward only;
forwarders {
On 14. 12. 22 16:55, Petr Menšík wrote:
Hi Vicky.
Excellent, thank you for the issue link.
Is backport to 9.18 decided already? Would it appear on minor updates in
9.18.x line? I see comment it needs some missing feature. Is that
temporary issue or already decided? It seems to be important
p
Hi Vicky.
Excellent, thank you for the issue link.
Is backport to 9.18 decided already? Would it appear on minor updates in
9.18.x line? I see comment it needs some missing feature. Is that
temporary issue or already decided? It seems to be important
prerequisite for Zero Trust initiative imp
> On Dec 14, 2022, at 10:12 AM, Petr Menšík wrote:
>
> Hello,
>
> I tried to find a way how to configure queries forwarding over encrypted
> channel. But unlike zone transfer and notifications, I have not found a way
> to configure query forwarding over DNS over TLS
Hello,
I tried to find a way how to configure queries forwarding over encrypted
channel. But unlike zone transfer and notifications, I have not found a
way to configure query forwarding over DNS over TLS even in latest
9.18.9 version.
Have I looked wrong? Is there some important limit why
"Garbage" records...
On Mon, 7 Nov 2022, Matus UHLAR - fantomas wrote:
On 07.11.22 15:42, Petr Špaček wrote:
That's part of normal resolver operation: Garbage in - garbage out -
garbage eventually cleaned out from cache. There is nothing special about
PTR records in that regard.
sooner or la
On 11/7/22 9:08 AM, Matus UHLAR - fantomas wrote:
I'm afraid that this problem can become really huge when someone creates
huge amount of generated records, e.g. using proposed module.
Even if BIND's cache is simply FIFO -- which I'm fairly certain that
it's smarter than that -- and flushes a
On 7. 11. 2022, at 16:19, Matus UHLAR - fantomas wrote:
while it's doable, and with using BIND plugin at generating server it
won't need much of memory, any server that will be repeatedly asked to
resolve IPs from that range will fill its cache with generated records.
On 07.11.22 16:28, Ondře
> On 7. 11. 2022, at 16:19, Matus UHLAR - fantomas wrote:
>
> while it's doable, and with using BIND plugin at generating server it won't
> need much of memory, any server that will be repeatedly asked to resolve IPs
> from that range will fill its cache with generated records.
That's not any
On 7. 11. 2022, at 15:50, Matus UHLAR - fantomas wrote:
sooner or later, but filling up cache with garbage could result in other
non-garbage records being flushed out.
Are there any mechanisms that would wipe this garbage before other records,
used more often even if not very recently?
On 07
> On 7. 11. 2022, at 15:50, Matus UHLAR - fantomas wrote:
>
>
> sooner or later, but filling up cache with garbage could result in other
> non-garbage records being flushed out.
> Are there any mechanisms that would wipe this garbage before other records,
> used more often even if not very r
On 28.10.22 08:26, Ondřej Surý wrote:
BIND 9 have support for writing plugins, and we would accept a
well written plugin that would allow generating the forward/reverse plugins on the fly.
There’s already a feature request for it here:
https://gitlab.isc.org/isc-projects/bind9/-/issues/1586
On 07. 11. 22 15:23, Matus UHLAR - fantomas wrote:
On 28.10.22 08:26, Ondřej Surý wrote:
BIND 9 have support for writing plugins, and we would accept a well
written
plugin that would allow generating the forward/reverse plugins on the fly.
There’s already a feature request for it here:
https
On 28.10.22 08:26, Ondřej Surý wrote:
BIND 9 have support for writing plugins, and we would accept a
well written plugin that would allow generating the forward/reverse plugins on the fly.
There’s already a feature request for it here:
https://gitlab.isc.org/isc-projects/bind9/-/issues/1586
On 28. 10. 22 9:29, Matus UHLAR - fantomas wrote:
On 28.10.22 08:26, Ondřej Surý wrote:
BIND 9 have support for writing plugins, and we would accept a well
written
plugin that would allow generating the forward/reverse plugins on the fly.
There’s already a feature request for it here:
https:
I recommend anyone who wants to deploy wildards to go read
https://slack.engineering/what-happened-during-slacks-dnssec-rollout/
There are lots of learning points there. You can skip to the "Solving
the mystery" section if you are familiar with the cover of the
Hitchhiker's guide to the Galaxy.
Y
> Do wildcard records work with multiple labels? I was thinking that they
> didn't, but it's that wildcards in PKIX do not work with multple labels,
> alas.
As far as I understand, yes, wildcard "works with multiple labels", at
least in the meaning that a wildcard can expand more than one label in
On 28.10.22 08:26, Ondřej Surý wrote:
BIND 9 have support for writing plugins, and we would accept a well written
plugin that would allow generating the forward/reverse plugins on the fly.
There’s already a feature request for it here:
https://gitlab.isc.org/isc-projects/bind9/-/issues/1586
BIND 9 have support for writing plugins, and we would accept a well written
plugin that would allow generating the forward/reverse plugins on the fly.
There’s already a feature request for it here:
https://gitlab.isc.org/isc-projects/bind9/-/issues/1586
The BIND 9 team just have been busy with
Marco writes:
> At least for IPv4, there are servers that reject connections from IPs
> that don't have a reverse zone with PTR record.
Yes.
But but no one in their right mind do that for IPv6. A missing PTR is
not indicating anything at all. You might as well reject connections
based on rand(
I tried back in 2013 to get the IETF to standardise delegating the reverse
tree when prefix delegations happen.
https://www.ietf.org/archive/id/draft-andrews-dnsop-pd-reverse-02.txt
named already supports updating PTR records based on the IP address of the
TCP connection making the UPDATE request
grant> I'd be interested in learning what other things /require/ or are
grant> at least predicated on having PTR records for IPs.
Been a few years since I last delved but was appalled at some of the
pointless uses of rev-ptrs. NYT used to require it to let you connect to
their website, as one such
On 10/27/22 4:18 PM, Andrew Latham wrote:
IRC for example will check for PTR and gate login. I know there are
others but that came to mind quickly. In some regions having PTRs was a
requirement. It has been years but I recall LACNIC required/desired PTRs
be set.
I wasn't aware of IRC's requir
IRC for example will check for PTR and gate login. I know there are others
but that came to mind quickly. In some regions having PTRs was a
requirement. It has been years but I recall LACNIC required/desired PTRs be
set.
On Thu, Oct 27, 2022 at 2:47 PM Grant Taylor via bind-users <
bind-users@list
On 10/27/22 1:24 PM, Marco wrote:
At least for IPv4, there are servers that reject connections from
IPs that don't have a reverse zone with PTR record.
Please elaborate.
I've not heard of (unspecified type of) servers rejecting connections
because of the lack of a PTR record.
I have heard o
Am 27.10.2022 um 13:08:40 Uhr schrieb Grant Taylor via bind-users:
> Aside: I do question what you would populate the /48 ~ /56 ip6.arpa
> zone with. What hypothetical data would you put in it? If it's PD
> to an end user, what information would the ISP put in there that
> wouldn't be confiden
On 10/27/22 11:23 AM, Marco wrote:
It isn't, because a customer gets /48 or /56 in most cases.
"For example one of their clients has the IP 2001:db::3." is a singular IP.
The customer's router can use various methods to assign addresses, auto
configuration and DHCPv6.
Agreed.
However that'
Hi Marco
Probably Knot could help here
(https://www.knot-dns.cz/docs/3.2/html/modules.html#synthrecord-automatic-forward-reverse-records)
where Knot is able to generate IPv6-PTR and IPv6- based on a pattern
"on-the-fly". Do you want to achieve something like this?
# Reverse-Lookup
$ dig
Am 27.10.2022 um 09:52:55 Uhr schrieb Grant Taylor via bind-users:
> This is a singular IP (presumably link-net) for a customer. So there
> would be exactly one forward and one reverse PTR record.
It isn't, because a customer gets /48 or /56 in most cases. The
customer's router can use var
On 10/27/22 1:16 AM, Marco Moock wrote:
Hello,
Hi,
how do ISPs automatically create the reverse and forwaring zones for
their customers IP pools?
I think it might be out of scope for what you were asking about, but I
believe the following is an alternative approach.
For example one of t
Marco writes:
> Did it create any problems if you don't have Reverse DNS for the IPv6
> addresses for normal customer traffic?
Not to my knowledge.
I've had support for semi-automatic delegation to customers on my
todo-list for ~10 years but never gotten around to actually doing
it. I'm sure a
> > It probably does not play well with DNSSEC, although I was thinking
> > about whether some amount of wildcards in the signed reverse could
> > help, but I don't think so.
>
> Well, what if the reverse is an NSEC3 does that let the server
> make up stuff with having to sign it al
> >To "fill" an ip6.arpa zone for a /64 requires 18446744073709551616
> > records (yes, that's about 18 x 10^18 if my math isn't off). I predict
> > you do not posess a machine capable of running BIND with that many
> > records loaded -- I know we don't.
>
> It sure would be ni
Havard Eidnes via bind-users wrote:
>To "fill" an ip6.arpa zone for a /64 requires 18446744073709551616
> records (yes, that's about 18 x 10^18 if my math isn't off). I predict
> you do not posess a machine capable of running BIND with that many
> records loaded -- I know we
>> Edit the corresponding REVERSE zone & add following line in the end
>>
>> $GENERATE 1-255 $ IN PTR 10-11-11-$.example.com.
>>
>> Dont forget to Reload bind config & you are done.
>
> Thanks.
> How is the syntax for IPv6?
> Is it possible to do it for an entire /64?
The full syntax of the $GENER
Am 27.10.2022 um 10:58:18 Uhr schrieb Bjørn Mork:
> Possible, but only for very small pools. Note that $GENERATE only is
> a short form for easier hand editing of zone files on the primary
> server. The zone is expanded on load and zone transfers etc will
> contain the expanded data set. It doesn
Marco Moock writes:
> Hello,
>
> how do ISPs automatically create the reverse and forwaring zones for
> their customers IP pools?
>
> For example one of their clients has the IP 2001:db::3.
We mostly don't do this for IPv6. It's a pointless exercise, IMHO.
We give every customer/site a /48. S
Am 27.10.2022 um 07:23:01 Uhr schrieb JAHANZAIB SYED:
Edit the corresponding REVERSE zone & add following line in the end
$GENERATE 1-255 $ IN PTR 10-11-11-$.example.com.
Dont forget to Reload bind config & you are done.
On 27.10.22 07:58, Marco wrote:
How is the syntax for IPv6?
the synta
Am 27.10.2022 um 07:23:01 Uhr schrieb JAHANZAIB SYED:
> Edit the corresponding REVERSE zone & add following line in the end
>
> $GENERATE 1-255 $ IN PTR 10-11-11-$.example.com.
>
> Dont forget to Reload bind config & you are done.
Thanks.
How is the syntax for IPv6?
Is it possible to do it for
oderators.isc.org
Subject: automatic reverse and forwarding zones
Hello,
how do ISPs automatically create the reverse and forwaring zones for
their customers IP pools?
For example one of their clients has the IP 2001:db::3.
Its reverse zone
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.
Hello,
how do ISPs automatically create the reverse and forwaring zones for
their customers IP pools?
For example one of their clients has the IP 2001:db::3.
Its reverse zone
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.d.0.0.1.0.0.2.ip6.arpa
includes a PTR pointing to
3.0.0.0.0.0.0.0.0.0.0
AWS are aware of the issue and are just taking a long time to address it.
noted.
pretty sure there's not a %*^$* thing i can do about THAT!
NXDOMAIN for ENTs can also be result of not adding delegating NS records
to the parent zone when both parent and child zones are served by the same
serve
> On 26 Oct 2022, at 11:25, PGNet Dev wrote:
>
>> QNAME minimisation is a good idea. It comes in two flavours, relaxed
>> and strict. Relaxed tries to cope with some breakages like NXDOMAIN
>> being returned from ENTs. Strict doesn’t.
>
> switch to 'relaxed' does, in fact, 'solve' the issue
QNAME minimisation is a good idea. It comes in two flavours, relaxed
and strict. Relaxed tries to cope with some breakages like NXDOMAIN
being returned from ENTs. Strict doesn’t.
switch to 'relaxed' does, in fact, 'solve' the issue. insofar as, it appears, i
no longer require the forward-zom
> On 26 Oct 2022, at 11:12, PGNet Dev wrote:
>
> hi,
>
>> AWS are returning NXDOMAIN instead of NOERROR for empty non terminals. Do
>> you have strict
>> qname minimisation turned on?
>
> yup, i do
>
> ...
> qname-minimization strict;
> ...
>
> only because my i understoo
hi,
AWS are returning NXDOMAIN instead of NOERROR for empty non terminals. Do you
have strict
qname minimisation turned on?
yup, i do
...
qname-minimization strict;
...
only because my i understood my reads of
BIND to Add QNAME Minimization
https://
00:9000:5301:8d00::1#53(ns-397.awsdns-49.com) (UDP)
;; WHEN: Wed Oct 26 10:35:57 AEDT 2022
;; MSG SIZE rcvd: 137
> On 26 Oct 2022, at 10:23, PGNet Dev wrote:
>
> i run bind 9.18.8
>
> i use root hints; forwarding is, by default, disabled in config
>
> with this config, i noti
i run bind 9.18.8
i use root hints; forwarding is, by default, disabled in config
with this config, i notice that although lookups for (e.g.) *.dock.io are
available in public NS caches, e.g.
dig A elb-default.us-east-1.aws.dckr.io @1.1.1.1
; <<>> DiG 9
Dan Mahoney writes:
We've seen a number of messages reported to us as having an isc.org "from"
address, and as having our dkim signatures, but the signatures failing to
verify, perhaps because a forwarder may have added a subject tag or
rewritten some other header. Of course, SPF also fails bec
Dan Mahoney writes:
> We've seen a number of messages reported to us as having an isc.org "from"
> address, and as having our dkim signatures, but the signatures failing to
> verify, perhaps because a forwarder may have added a subject tag or
> rewritten some other header. Of course, SPF also
Hey all,
I'm one of the people who admins ISC's mail servers, and also receives all
our DKIM/SPF/DMARC failure reports. (We use dmarcian.com)
We've seen a number of messages reported to us as having an isc.org "from"
address, and as having our dkim signatures, but the signatures failing to
ve
-> DMZ DNS Cache -> World
>
> Internal DNS is forward only. Only internal DNS allowed on the DNS
> cache systems. DNSSEC validation can be enabled or disabled on the
> cache systems since named always sets the check disabled flag when
> forwarding. This also means that yo
On 2022-04-13 17:08, Nicholas Miller wrote:
I believe this is the option you are looking for:
validate-except { domain.example; };
rndc nta domain.example
remember to define nta ttl in named.conf
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
. There
is always another domain that crops up and will need to be exempted.
The option I was looking for, which doesn't seem to exist is turning
off named setting the check disable flag when forwarding to another
system. With that ability, we could have moved DNSSEC validation
to the c
nal DNS allowed on the DNS
> cache systems. DNSSEC validation can be enabled or disabled on the
> cache systems since named always sets the check disabled flag when
> forwarding. This also means that you can't forward to an upstream
> DNS system and have it do the DNSSEC validation.
ache systems since named always sets the check disabled flag when
forwarding. This also means that you can't forward to an upstream
DNS system and have it do the DNSSEC validation. Wish there was a
way to turn this off or if it would only set the check disabled
flag when DNSSEC validation is enabled.
On 4/12/22 7:18 PM, Duchscher, Dave J via bind-users wrote:
We are dropping this configuration and looking at doing something else.
I'm sorry to hear that.
We have had intermittent issues with Slack, Microsoft, and a growing
list of domains. Even have one that consistently fails.
Are you ab
validation doesn't work for queries from the internal DNS server.
> > Doing DNSSEC validation on the internal DNS server that is forwarding to
> > the main DNS server has been problematic with some domain failing
> > intermittently and others just not working at all. Is there a
queries from the internal DNS server.
> Doing DNSSEC validation on the internal DNS server that is forwarding to
> the main DNS server has been problematic with some domain failing
> intermittently and others just not working at all. Is there a way to
> allow the main DNS server handl
on on the internal
DNS server that is forwarding to the main DNS server has been problematic with
some domain failing intermittently and others just not working at all. Is there
a way to allow the main DNS server handle DNSSEC validation?
Here is my test setup on my laptop:
First named c
amic routeing as an analogy, it's a bit like BGP needing
> to choose which is the best prefix by running through its decision
> algorithm.
> In BIND, authority trumps all; there is nothing higher. Next comes
> forwarding.
>
> BIND isn't the only DNS server software that d
far superior option - since
it's much more simple and straight-forward.
Consider it solved.
If ISC can confirm that behavior for forwarding a child domain when the server
is also auth for the parent zone, that would be very nice!
Thanks to everyone, again, for the help!
>
uld be rather painful. Unless there's some horrible
> consequences, I think we'll just continue for now. We won't ever use mDNS.)
>
> zone "ab.somedomain.local" {
> type forward;
> forward only;
> forwarders { 10.0.0.1; 10.0.0.2; 10.0.0.3; };
> };
>
> But
n.local" {
>> type forward;
>> forward only;
>> forwarders { 10.0.0.1; 10.0.0.2; 10.0.0.3; };
>> };
>> But this doesn't appear to do what I want.
>>
>> If I add the above to my regular BIND servers configuration, it doesn't
>> return
is reserved now, but we've been using it a long time
>>>> and changing would be rather painful. Unless there's some horrible
>>>> consequences, I think we'll just continue for now. We won't ever use mDNS.)
>>>>
>>>> zone "a
r now. We won't ever use mDNS.)
>
> zone "ab.somedomain.local" {
> type forward;
> forward only;
> forwarders { 10.0.0.1; 10.0.0.2; 10.0.0.3; };
> };
>
> But this doesn't appear to do what I want.
>
> If I add the above to my regular BIND server
On 3/1/22 5:35 AM, Matus UHLAR - fantomas wrote:
you are right, forwarding queries requires recursion.
Thank you for the confirmation Matus. :-)
--
Grant. . . .
unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
--
Visit https://lists.isc.org/mailman/listinfo/bind-users
t, if any, sort of restrictions you are placing on
recursion on your system.
It's my (mis)understanding that recursion has some effect on
forwarding queries. My limited understanding is recursion is another
way of saying if the server should chase the answer for you or not.
If it doesn&#
cursion on your system.
It's my (mis)understanding that recursion has some effect on forwarding
queries. My limited understanding is recursion is another way of saying
if the server should chase the answer for you or not. If it doesn't
have it in it's own data (authoritat
consequences, I think we'll just continue for now. We won't ever use mDNS.)
>
>
> zone "ab.somedomain.local" {
> type forward;
> forward only;
> forwarders { 10.0.0.1; 10.0.0.2; 10.0.0.3; };
> };
>
> But this doesn't appear to do what I want.
>
>
x27;ll just continue for now. We won't ever use mDNS.)
>>
>> zone "ab.somedomain.local" {
>> type forward;
>> forward only;
>> forwarders { 10.0.0.1; 10.0.0.2; 10.0.0.3; };
>> };
>> But this doesn't appear to do what I want.
>>
forwarders { 10.0.0.1; 10.0.0.2; 10.0.0.3; };
> };
>
> But this doesn't appear to do what I want.
>
> If I add the above to my regular BIND servers configuration, it doesn't
> return results like it's forwarding them. (I get NXOMAIN for
> abc.ab.somedomain.
he above to my regular BIND servers configuration, it doesn't return
results like it's forwarding them. (I get NXOMAIN for abc.ab.somedomain.local.)
If I do a dig @10.0.0.1 abc.ab.somedomain.local from the BIND server, I get a
proper result. (force dig to use the AD name servers directly, in
k:
>
>
>
> 1. Adding a forward for this subdomain:
>
>
>
> zone "titi.toto.be." {
>
> type forward;
>
> forwarders {1.2.3.4; 5.6.7.8;}; (ip’s from dsn cache servers)
>
> forward only;
>
> };
>
>
>
> * Seems not to work.
;}; (ip's from dsn cache servers)
forward only;
};
* Seems not to work. Not possible to add a subdomain forwarding?
it is possible, but will only work for recursive clients of your DNS server.
1. Using directly the cache servers as NS:
Cache.proximus.be. INA
rd only;
};
* Seems not to work. Not possible to add a subdomain forwarding?
1. Using directly the cache servers as NS:
Cache.proximus.be. INA 1.2.3.4
Cache.proximus.be. INA 5.6.7.8
Titi.toto.be. INNS cache.proximus.be.
* Not al
Fred Morris wrote:
>
> What I'm looking at is trying to build a BIND kernel, like a nanokernel. Socat
> won't work in this case, because because there's no "IPC" layer, because there
> is only one process in the kernel.
Sounds fun. I think your solution must be to modify BIND's dnstap sender
so t
I should have included this in the first message, and I apologize.
What I'm looking at is trying to build a BIND kernel, like a nanokernel.
Socat won't work in this case, because because there's no "IPC" layer,
because there is only one process in the kernel.
One process. No users. I need to
for sending this to another address, presumably
via TCP... socat? Too bad about the handshake, any best practices for
forwarding there?
Thanks in advance...
(Pure Python implementation of fstrm:
https://github.com/m3047/shodohflo/blob/master/shodohflo/fstrm.py
1 - 100 of 420 matches
Mail list logo
