On Fri, 2023-05-26 at 16:51 +0530, Shailendra Gautam wrote:
> Does bind provide any way to manage(add,update,delete) resource
> records
> with HTTP API, like powerdns?
Not TTBOMK. It does have an API for managing RRs but that is using RFC
2136 and not HTTP.
> I currently use zonefiles to store D
I am trying to do some testing of an IPv6-only network here using some
nat64 to reach the "legacy" :-) IPv4 Internet. My network is currently
dual-stack.
I have dns64 query mapping working, but I am still seeing some clients
that I am trying to test with (that still have IPv4 addresses until the
On Sun, 2022-02-20 at 08:16 +1100, Mark Andrews wrote:
>
> EDNS is hop by hop. There is no copying by any compliant server.
Fair enough. I thought it was a long shot.
Cheers,
b.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the developme
On Sat, 2022-02-19 at 19:02 +0100, Matus UHLAR - fantomas wrote:
>
> what's the point of this setup?
> BIND can resolve by itself perfectly and you wouldn't rely on 3rd
> party
> service
Except that it cannot do EDE, as I already said in my original message.
Cheers,
b.
signature.asc
Descri
I have a BIND9 server configured as a resolver for the local network to
forward all requests to 1.1.1.1. Given that that 1.1.1.1 includes
(RFC8914) EDE EDNS options in it's responses, can I configure the BIND
resolver to forward those EDNS options in it's response to the client?
While I know BIND
I'm really not sure about what the name of this feature I am going to
describe would be. I would probably call it an "overlay view". But I
am sure there are better names.
Imagine I have a BIND 9 server for the following network topology:
Network 1
192.168.1.0/24 -
On Wed, 2018-01-17 at 10:45 -0500, Brian J. Murrell wrote:
> I have a BIND (9.9.4)[1] server that runs well most of the time, but
> periodically it will start returning SERVFAIL for very high-level
> domains such as *.google.com, *.gstatic.com, *.github.com, etc. It
> seems to
On Tue, 2018-01-23 at 09:53 -0700, Grant Taylor via bind-users wrote:
>
> Could you try disabling DDNS updates for a little while?
That's effectively what I have done.
I set up a second server configuration running new zone on a different
IP address and pointed the DHCP server at it so that the
On Tue, 2018-01-23 at 13:38 +0100, Reindl Harald wrote:
>
> pretty sure it's possible and likely not much different than the
> unbound-sample below which asks a rbldnsd on port 1043 on the same
> machine
>
> stub-zone:
> name: "zone-name."
> stub-addr: 127.0.0.1@1053
This all falls apart be
On Tue, 2018-01-23 at 13:38 +0100, Reindl Harald wrote:
>
> pretty sure it's possible and likely not much different than the
> unbound-sample below which asks a rbldnsd on port 1043 on the same
> machine
>
> stub-zone:
> name: "zone-name."
> stub-addr: 127.0.0.1@1053
That's the sort of path
Here's a new most interesting data point.
All of these outages happen right after a DHCP client connect and sends
a DDNS update to BIND.
It would be an interesting experiment to isolate the zone that receives
DDNS updates for the DHCP clients onto a separate server to see if that
makes this probl
On Mon, 2018-01-22 at 12:45 +, Tony Finch wrote:
>
> lame-servers is also a log category, and tends to be quite noisy
> about
> various problems :-)
Turns out I do already have lame server logging enabled. I.e.:
20-Jan-2018 12:01:37.053 lame server resolving 'backup-ns.yn.cninfo.net' (in
'
On Mon, 2018-01-22 at 16:10 +, Tony Finch wrote:
>
> You should make sure it is enabled, because there are vital clues in
> those
> log lines :-)
But they will only occur if there is some lameness with the ns[1-
4].google.com records and that will already be reported with lame:n in
the "fetch
On Mon, 2018-01-22 at 12:04 +, Tony Finch wrote:
>
> The thing to look out for is the minutes before the outage starts -
> see
> what kind of failures you get.
So, taking this approach, looking for the first occurrence of just any
one of the names ns[1-4].google.com prior to the A/ querie
On Mon, 2018-01-22 at 12:45 +, Tony Finch wrote:
>
> They'll have a log category of edns-disabled.
But if the problem were EDNS, would it be so intermittent and always
fixable by rndc reload?
> But, looking through the
> code, if this is leading to lameness you will also get lame-servers
> l
On Mon, 2018-01-22 at 12:04 +, Tony Finch wrote:
>
> That indicates that it has already marked the servers as lame, so the
> packet trace isn't going to tell you what caused the lameness.
OK.
> The thing to look out for is the minutes before the outage starts -
> see
> what kind of failures
OK. I now have named trace logging
http://brian.interlinx.bc.ca/named.run.log
and a packet dump:
http://brian.interlinx.bc.ca/dns-packets.txt
that demonstrates how BIND is getting .com referrals from the root
servers when doing a query for www.google.com and then doing nothing
with those refer
On Fri, 2018-01-19 at 15:22 +, Tony Finch wrote:
>
> You don't have any weird middleboxes between your resolver and the
> Internet, do you?
I don't believe so. Not entirely sure what "weird middleboxes" refers
to in this context though. And by resolver are you referring to my
BIND9 server o
On Fri, 2018-01-19 at 14:54 +, Tony Finch wrote:
>
> Those responses look like referrals from the root servers to the .com
> servers;
Ahhh. Right. That makes sense.
> I would expect you to see `named` repeating the queries as it
> follows the iterative resolution algorithm.
Indeed. I wil
On Thu, 2018-01-18 at 17:46 +, Tony Finch wrote:
> Brian J. Murrell wrote:
> > On Thu, 2018-01-18 at 15:41 +, Tony Finch wrote:
> > >
> > > The default is 10 minutes - try reducing it and see if the outage
> > > becomes shorter.
> >
> &
On Thu, 2018-01-18 at 15:41 +, Tony Finch wrote:
>
> Does the time to recovery correspond to the lame-ttl setting?
I am not sure. I'm not always aware of when it starts. I guess if I
am running a trace level permanently the log would tell me though.
> The default
> is 10 minutes - try redu
I have a BIND (9.9.4)[1] server that runs well most of the time, but
periodically it will start returning SERVFAIL for very high-level
domains such as *.google.com, *.gstatic.com, *.github.com, etc. It
seems to happen most frequently with Google domains, but I wonder if
that is just a reflection o
Trying to follow an example I found of manually verifying a name's
DNSSEC records I did the following:
# dig . DNSKEY | grep -Ev '^($|;)' > root.keys
# dig +sigchase +trusted-key=./root.keys www.eurid.eu. A
That resulted in some errors but more importantly the following in my
syslog:
Mar 23 08:1
On 12-07-24 07:53 AM, Phil Mayers wrote:
> On 24/07/12 12:05, Brian J. Murrell wrote:
>
> Change ISP?
A. You must be one of those people who live in that part of the
world where internet service providing is not a monopoly, duopoly or at
best a price-fixing oligopoly. :-) Unfo
On 12-07-24 07:05 AM, Brian J. Murrell wrote:
> I've come across something interesting in my named logs:
>
> 00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache)
> '5.37.58.216.in-addr.arpa/PTR/IN' denied
> 00:14:37 named client 205.166.7
I've come across something interesting in my named logs:
00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:
On 12-07-20 07:16 PM, Mark Andrews wrote:
>
> "dnssec-validation auto;"
Well, this seems to have done the trick. Changing it from yes to auto
has eliminated most (almost all in fact) of the validation
warnings/errors I was getting in my logs.
> tells named to use the compiled
>
On 12-07-20 11:40 AM, Mark Andrews wrote:
>
> In message <500978a5.4070...@imperial.ac.uk>, Phil Mayers writes:
>> On 20/07/12 16:21, Mark Andrews wrote:
>>>
>>> In message <50096c2b.1080...@interlinx.bc.ca>, "Brian J. Murrell" writes:
>>
On 12-07-20 10:42 AM, Mark Andrews wrote:
>
> The NS RRset is the delegation records and as such has no RRSIGs.
> If you turn on minimal-responses the NS rrset won't be added and
> AD won't be cleared. AD is only set to 1 if all the records in the
> answer and authority sections are marked as se
On 12-07-20 09:11 AM, Phil Mayers wrote:
>
> Or, what happens if you start bind up in debug mode and run the query?
> There will be a lot of output, but I've found most problems to be fairly
> obvious if you read through it.
Yeah, there is a lot of output. Too big of a haystack for me to find
th
On 12-07-20 08:34 AM, Brian J. Murrell wrote:
>
> The problem here seems to be fragmented UDP.
I seem to have misdiagnosed this due to tcpdump peculiarities. I only
initially saw/suspected the problem since my capture for port 53
packets was including (only the first) ipv4 fragments.
On 12-05-15 09:01 AM, Phil Mayers wrote:
>
Sorry about the way delayed response. There seems to be some confusion
about which list/group gmane is following.
> Isn't it more likely it's a local problem?
Indeed. But what, is the question (and I do have the answer, now --
see below).
> Which v
On 12-05-02 09:29 AM, Mark Andrews wrote:
>
> * a firewall blocking EDNS queries.
> * using a non DNSSEC enabled forwarder so you don't get signatures.
> * a firewall blocking fragmented UDP and named falling back to
> plain DNS.
> * other packet loss causing named to fallback to plain DNS.
Gi
On 12-05-02 09:29 AM, Mark Andrews wrote:
>
>
> The zones are signed. Possible reason are:
>
> * a firewall blocking EDNS queries.
This shouldn't be the case. Outgoing traffic from the bind9 server
being used here should be completely unfettered.
> * using a non DNSSEC enabled forwarder so y
Not having dipped my toe into DNSSEC yet (yes, I know, but time is
always so scarce)...
So I am seeing a bunch of this sort of thing in my BIND logs now:
04:02:18 named validating @0xb0f58988: 124.in-addr.arpa SOA: no valid signature
found
04:02:18 named validating @0xb0f58988: 124.in-addr.arpa
On 11-06-24 03:19 PM, David Sparro wrote:
>
> Do you have control of the update process.
Sure.
> You could potentially send
> and update to both views (in other words, send two updates).
How do I, with nsupdate, specify which view's zone I want to update?
> I think
> you'd need separate zone f
On 11-06-24 01:47 PM, Evan Hunt wrote:
>
> Do the internal and external versions *both* need to be dynamic?
No, only the internal in fact.
> I'd expect it to work okay if you had only one of them dynamic, and
> sent periodic reload commands to the other one.
Yeah. I got the master/slave appro
On 11-06-24 12:39 PM, Evan Hunt wrote:
>
> You can specify the view in the reload command:
>
> $ rndc reload example.com in external
But reload doesn't work for dynamic zones:
# rndc reload rbl.interlinx.bc.ca in greatunwashed
rndc: 'reload' failed: dynamic zone
and since I want the sa
On 11-06-24 09:57 AM, Lyle Giese wrote:
>
> It's expected behavior in a way.
Given your explanation, indeed. :-)
> You are probably making this change in
> the internal view and the internal named process knows about the change
> and reloads the zone.
>
> The external view's process is unaware
I am using BIND 9.7.2-P2.
I have two views, one "internal" and one for "external" queries. In
both of those views I have some zones which are common so I put them
into their own file "zones.common" and include that file in both of the
views.
The problem I am having is that when I make a dynamic
Jeremy C. Reed isc.org> writes:
>
> I was reading it all along, but could never reproduce.
Given the new information I have, I'll hazard to guess that you were trying to
reproduce with something newer than 9.7.0-P2.
> I thought it was
> a temporary issue.
>
> I see your new bug report. Some
Casey Deccio deccio.net> writes:
>
> I still don't have the answer to this.
Fair enough. I was just looking for clarification on your previous statements.
> Perhaps a BIND developer may
> have better insight into the log messages and what may be going on.
Yeah, I was hoping to have caught th
Casey Deccio deccio.net> writes:
>
> After a review of NSEC3 showed that this particular behavior is
> expected because org has been signed using NSEC3 with the opt-out bit
> set.
I'm afraid I'm getting a bit lost due to my real lack of understanding of the
details of DNSSEC. I wish I had the
Brian J. Murrell interlinx.bc.ca> writes:
>
> Casey Deccio deccio.net> writes:
> >
> > Do you get a NOERROR response with the AD bit set?
>
> Yup:
> ...
Was any of that information I posted in the previous message useful? If not,
Casey Deccio deccio.net> writes:
>
> On Tue, Nov 9, 2010 at 8:10 PM, Brian J. Murrell interlinx.bc.ca>
wrote:
> > $ dig @linux -p 1053 41.70.55.206.sa-trusted.bondedsender.org txt
Doh! I forgot the +dnssec.
> What happens when you run the following queries:
>
>
Casey Deccio deccio.net> writes:
>
> Reproducing these errors and analyzing the debug-level log messages
> would be helpful since everything looks consistent from a DNSSEC
> perspective, as far as I can see.
Well, I have attempted this. I reproduced my existing bind configuration and
added the
Casey Deccio deccio.net> writes:
>
> This can happen in a number of different ways: If any RRSIGs in the
> chain of trust are bogus, expired, or missing. If NSEC/NSEC3 records
> are not provided or are insufficient to prove that no DS records exist
> for an insecure delegation. If DS RRs do e
Stephane Bortzmeyer nic.fr> writes:
>
> They are not name servers of sa-trusted.bondedsender.org:
Damn. Yes, you are correct. I forgot it was sa-trusted.bondedsender.org. in
our example and stopped at bondedsender.org. However going that one more sub-
domain deeper and testing it's NSes, the
Stephane Bortzmeyer nic.fr> writes:
>
> Indeed. Your analysis seems right. May be you have somewhere another
> trust anchor (for DLV ISC or directly for bondedsender.org?)
Hrm. I'm not sure TBH. I know I didn't install any trust anchor specifically
for bondedsender.org, but I do have "dnsse
Casey Deccio deccio.net> writes:
>
> There is a difference between a "broken" trust chain and a trust chain
> that securely "ends" before reaching the name being queried.
Ahhh. That makes sense.
> However, a broken chain means that the validating resolver expects a
> chain to exist, but the c
Alan Clegg isc.org> writes:
>
> On 11/2/2010 8:11 AM, Brian J. Murrell wrote:
> >
> > named error (broken trust chain) resolving '133.168.163.66.sa-
> > trusted.bondedsender.org/TXT/IN': 173.45.100.146#53
> There isn't a chain of signed DS records
Alan Clegg isc.org> writes:
>
Hi Alan,
> There isn't a chain of signed DS records that lead from a trust anchor
> to the thing that you are trying to resolve.
I guess I'm going to have to learn a bit more about DNSSEC in order to parse
that. :-)
Are there any good tutorials on the mechanics
Since enabling DNSSEC on my resolving server I have been seeing various
instances of the following sort of messages:
named error (broken trust chain) resolving '133.168.163.66.sa-
trusted.bondedsender.org/TXT/IN': 173.45.100.146#53
named error (broken trust chain) resolving
'173.65.147.69.bb.bar
53 matches
Mail list logo
