h a large
portfolio of domains and disparate TLDs.
regards
Al
On 6/6/2024 08:46, Andrew Latham wrote:
Link for the Debian packaged version you mentioned is at
https://bind9.readthedocs.io/en/v9.18.24/reference.html#namedconf-statement-dnssec-policy
On Thu, Jun 6, 2024 at 9:31 AM Andrew Lath
). With large numbers of domains, there will always be a mix of
algorithms. Relations with other organizations can slow down
conversions from older algorithms to new ones.
My main point here is that I am not just trying to get bind to not 'time
out' my keys (with 'lifetime unlimi
As far as I have been able to determine through some fairly extensive
reading, a feature I depend on has fallen out of favor with the BIND
developers, and is being removed.
DNSSEC in 9.18 has two automatic actions where the original code had
just one, and the second cannot be disabled.
I am ref
named.conf file.
Will the logic work as I stated above?? Any comments from the experts will be
great for me.
(N.B. I came to know that, resolving different IP based on different source can
be possible in KNOT DNS, but I would be happy to do it in BIND (if possible).
XX.XX.XX.XX;
};
options {
notify explicit;
allow-notify { "MASTER"; };
...
}
==
Any assistance would be appreciated.
Thanks,
AL
___
Please visit https://lists.isc.org/mailman/listi
.
The client IP,source port and Server IP is the same in these queries. Is
this the right BIND behavior in this case or it is an issue.
Regards,
Naser Al Hattab.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from
test
--
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Does anyone know what might be causing these bind error messages?
BIND
Apr 6 10:01:51 named[690]: [ID 12345 daemon.error] client
10.10.10.10#54672: transfer of 'com.kw/IN': send: socket is not connected
Currently we have 6 clients
Thanks
Youssif
_
l"
What?!
And all this time I just assumed it was the Martian Sand variety that
was being spoken of on all the "save the whales" bumper stickers.
Maybe Al will end up winning the Darwin Award for another one of his
avante garde ideas. He'll decide that the conventional wis
2009 11:17 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Al Stu wrote:
History is fraught with individuals or a few being ridiculed for putting
forth that which goes against the conventional wisdom of the masses and
so called experts, only to be
MX Records are NOT
"Illegal"
On Sat, 2009-01-31 at 16:55, Al Stu wrote:
History is fraught with individuals or a few being ridiculed for putting
forth that which goes against the conventional wisdom of the masses and so
You don't get to speak for anyone else but yourself, j
same logic automobiles
should also be abolished and we should all just go back to horse and buggy.
Oh wait, those too should be abolished based on that same logic.
- Original Message -
From: "Michael Milligan"
To: "Al Stu"
Cc:
Sent: Friday, January 30, 2009 10:20 AM
Subj
of day.
Once upon a time the world was 'flat'. For some of you, apparently is still
is 'flat'.
- Original Message -
From: "Michael Milligan"
To: "Al Stu"
Cc:
Sent: Friday, January 30, 2009 10:20 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs.
Analyze this.
Query MX dns.com
Response MX nullmx.domainmanager.com
Query A nullmx.domainmanager.com
Response CNAME mta.dewile.net, A 64.40.103.249
See attached network trace.
No. TimeSourceDestination Protocol Info
1 0.00192.168.1
em in the group ***
- Original Message -
From:
To:
Sent: Tuesday, January 27, 2009 9:52 AM
Subject: e: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Al Stu" wrote:
How about these two?
nullmx.domainmanager.com
Non-authoritative answer:
Name:mta.dew
Tuesday, January 27, 2009 9:01 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
On 27.01.09 08:46, Al Stu wrote:
So then you disagree that the following example returns a valid address
record for srv1?
srv1 300 IN A 1.2.3.4
mx1 300 IN CNAME srv1.
A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com,
1.2.3.4, and also delivers the alias (CNAME) record of "mx1.xyz.com".
*** PLEASE don't copy me on replies, I'll read them in the group ***
- Original Message -
From: "Mark Andrews&q
I'll read them in the group ***
- Original Message -
From: "Mark Andrews"
To: "Al Stu"
Cc:
Sent: Monday, January 26, 2009 6:17 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
In message <0aa37ce829ba458b9ba2d
x27;ll read them in the group ***
- Original Message -
From: "Mark Andrews"
To: "Al Stu"
Cc:
Sent: Monday, January 26, 2009 10:03 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
In message , "Al Stu" write
nd alias, which in turn when submitted for an A
query results in both the A and CNAME being returned. Thus meeting the SMTP
RFC requirements.
- Original Message -
From: "Mark Andrews"
To: "Al Stu"
Cc:
Sent: Monday, January 26, 2009 8:41 PM
Subject: Re: BIND
tt Haneda"
To: "Al Stu"
Cc:
Sent: Monday, January 26, 2009 8:09 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
On Jan 26, 2009, at 7:54 PM, Al Stu wrote:
If you refuse a CNAME then it is your SMTP server that is broken. The
SM
If you refuse a CNAME then it is your SMTP server that is broken. The SMTP
RFC's clearly state that SMTP servers are to accept and lookup a CNAME.
- Original Message -
From: "Scott Haneda"
To: "Mark Andrews"
Cc: "Al Stu" ;
Sent: Monday, January
there is
no need for this.
And no it does not matter if there are multiple MX records with different
preferences values.
- Original Message -
From: "Mark Andrews"
To: "Al Stu"
Cc:
Sent: Monday, January 26, 2009 2:55 PM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A
l"
On Tue, 2009-01-27 at 07:43, Danny Thomas wrote:
Al Stu wrote:
> So within the zone SMTP requirements are in fact met when the
> MX RR is a CNAME.
you might argue the line of it being OK when additional processing
includes an A record.
In all the time its taken him to t
"Thus, if an alias is used as the value of an NS or MX record, no address
will be returned with the NS or MX value."
Above statement, belief, perception etc. has already been proven to be a
fallacy (see the network trace attached to one of the previous messages).
Both the CNAME and A record is
No it is only two steps, see the attachment (sent in previous message).
Both the CNAME and A record are returned for the mx.xyz.com DNS A request.
And this does met the RFC requirements.
- Original Message -
From: "Matthew Pounsett"
To: "Al Stu"
Cc:
Sent: Sund
Attachment (hopefully)
- Original Message -
From: "Al Stu"
To:
Sent: Sunday, January 25, 2009 10:15 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT
"Illegal"
Yes, blah was supposed to be srv1.
I do receive both the CNAME and
was replaced with srv1
3) server ip address was replaced with 1.2.3.4
Requirements are met.
- Original Message -
From: "Matthew Pounsett"
To: "Al Stu"
Cc:
Sent: Sunday, January 25, 2009 9:49 AM
Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Recor
No I do not believe an extra step was added. Take the following example for
instance.
STMP server smtp.xyz.com. needs to send a message to some...@xyz.com. An MX
lookup is performed for domain xyz.com. and the domain name of mx.xyz.com is
returned. This is the first sentence:
"When a do
Records are NOT
"Illegal"
At 22:11 24-01-2009, Al Stu wrote:
Some people seem to think RFC 974 creates a standard which prohibits the
use of CNAME/alias in MX records. But very much to the contrary RFC 974
demonstrates that CNAME/alias is permitted in MX records.
RFC 974 is obs
RFC 2821 is much more recent and clearly documents in sections 3.5 and 5
that CNAME MX RR are permitted and are to be handled by SMTP MTA's.
3.6 Domains
"Only resolvable, fully-qualified, domain names (FQDNs) are permitted when
domain names are used in SMTP. In other words, names that can be r
ect and
just an attempt by ISC to get people to go along with what is only a perceived
rather than actual standard/requirement, and should be removed so as not to
further the fallacy of this perceived perception of a standard/requirement, as
it is neither a standard nor a requ
32 matches
Mail list logo
