Viktor Dukhovni wrote on 2019-11-18 12:56:> ...
At the end of the day, operating outside the RFC carries some risk,
and one should not be cavalier in deploying creative deviations from
the spec. However, post-MX CNAME indirection is seen to useful by
some to stick to the spec, and since MTAs
> On Nov 18, 2019, at 1:00 PM, Paul Vixie wrote:
>
> A correct implementation of SMTP could pick up the A and from
> additional data without making any additional queries.
Some resolvers return "minimal" answers and don't include additional
records. MTA's can't rely on getting addresses in
a correct implemention of smtp could pick up the a and from additional
data without making any additional queries. it could also ignore cname records
in the a/ response and declare that the a/ owner was wrong.
we can't break working behaviour no matter what the statistics show. a dr
> On Nov 17, 2019, at 8:35 PM, Mark Andrews wrote:
>
> Just because broken configuration don’t always cause problems doesn’t mean
> that they don’t sometimes. MTA’s need to know what names they are known
> by to properly remove MX records from consideration when performing store and
> forward. E
> On 17 Nov 2019, at 17:20, Viktor Dukhovni wrote:
>
>> On Nov 16, 2019, at 9:41 AM, John Levine wrote:
>>
>> Remember that it's invalid for an NS or MX to point to a CNAME so I assume
>> it's equally invalid for them to point to a DNAME.
>
> There's no need for NS RRs pointing the non-canon
> On Nov 16, 2019, at 9:41 AM, John Levine wrote:
>
> Remember that it's invalid for an NS or MX to point to a CNAME so I assume
> it's equally invalid for them to point to a DNAME.
There's no need for NS RRs pointing the non-canonical names, the DNAMEs
are there for continuity (or to support al
Apologies, all, that was supposed to go off-list. I have an employer
(ISOC), not speaking for it, &c &c.
A
On Sat, Nov 16, 2019 at 11:33:50PM -0500, Andrew Sullivan wrote:
> On Sat, Nov 16, 2019 at 10:41:51PM +0800, John Levine wrote:
> > Remember that it's invalid for an NS or MX to point to a
On Sat, Nov 16, 2019 at 10:41:51PM +0800, John Levine wrote:
> Remember that it's invalid for an NS or MX to point to a CNAME so I assume
> it's equally invalid for them to point to a DNAME.
They couldn't point to a DNAME, but they could point to a target that
would resolve through a DNAME-using
On Thu, Nov 14, 2019 at 6:40 AM Shane Kerr
wrote:
> Hello,
>
> We just implemented DNAME support on an authoritative server that
> already implements giving an HINFO response to ANY queries, as described
> in RFC 8482.
>
> RFC 8482 is clear about not allowing the HINFO response if there is a
> CN
In article <6bb18d2f-4701-41cf-9b50-9ee8541ed...@dukhovni.org> you write:
>> On Nov 14, 2019, at 1:50 PM, John Levine wrote:
>>
>> PS: I'm also coming to the conclusion that if you think DNAME solves
>> your problem, and your problem isn't the arcane IPv6 rDNS renumbering
>> for which it was inve
> On Nov 14, 2019, at 1:50 PM, John Levine wrote:
>
> PS: I'm also coming to the conclusion that if you think DNAME solves
> your problem, and your problem isn't the arcane IPv6 rDNS renumbering
> for which it was invented, you don't understand DNAME.
As you may recall,
http://mailarchive.ie
John Levine wrote:
>
> PS: I'm also coming to the conclusion that if you think DNAME solves
> your problem, and your problem isn't the arcane IPv6 rDNS renumbering
> for which it was invented, you don't understand DNAME.
We're using it to reduce the number of IPv4 reverse DNS zones, for which
it
Shane Kerr wrote:
> On the other hand, it seems unlikely that any resolver actually sends
> ANY queries to authoritative servers.
This happens when the resolver's cache doesn't have an entry for the name,
so the resolver sends the ANY query to the authoritative servers. It's
rare because ANY que
> On Nov 14, 2019, at 9:40 AM, Shane Kerr wrote:
>
> We have chosen to perform CNAME synthesis for ANY queries that match a DNAME
> subtree, based on the logic that if CNAME is special when added by hand then
> it is probably also special when synthesized.
>
> I'm interested in what the DNSOP
In article you write:
>We have chosen to perform CNAME synthesis for ANY queries that match a
>DNAME subtree, based on the logic that if CNAME is special when added by
>hand then it is probably also special when synthesized.
That seems reasonable, but since the point of 8482 was that ANY
querie
Hello,
We just implemented DNAME support on an authoritative server that
already implements giving an HINFO response to ANY queries, as described
in RFC 8482.
RFC 8482 is clear about not allowing the HINFO response if there is a
CNAME record at the name. While no rationale is given in the RF
16 matches
Mail list logo
