On Thu, Nov 1, 2018 at 5:14 PM John Levine wrote:
> I can't help but note that people all over the Internet do various
> flavors of ANAME now, and the DNS hasn't fallen over. Let us not make
> the same mistake we did with NAT, and pretend that since we can't find
> an elegant way to do it, we ca
I can't help but note that people all over the Internet do various
flavors of ANAME now, and the DNS hasn't fallen over. Let us not make
the same mistake we did with NAT, and pretend that since we can't find
an elegant way to do it, we can put our fingers in our ears and it
will go away.
In artic
Greetings, DNSOP folks.
First, a disclaimer and perspective statement:
These opinions are mine alone, and do not represent any official position
of my employer.
However, I will note that it is important to have the perspective of one
segment of the DNS ecosystem, that of the authority operators (a
On Thu, Nov 1, 2018 at 12:09 PM Joe Abley wrote:
> On 1 Nov 2018, at 15:06, Brian Dickson
> wrote:
>
> > Maybe signaling the algorithm(s) for which signature(s) are
> desired/understood would do the trick?
>
>> > I.e. in an EDNS option?
>>
>> I don't think so. EDNS options relate to servers exch
On 1 Nov 2018, at 15:14, Wes Hardaker wrote:
> Russ Housley writes:
>
>> It is a good time to do rfc5011-bis. Real world experience from the
>> KSK roll makes a lot os sense to me.
>
> I think step one would be to list the aspects of it that worked well,
> and the aspects that didn't. From t
Russ Housley writes:
> It is a good time to do rfc5011-bis. Real world experience from the
> KSK roll makes a lot os sense to me.
I think step one would be to list the aspects of it that worked well,
and the aspects that didn't. From that we can determine the need for a
replacement and what fe
On 1 Nov 2018, at 15:06, Brian Dickson wrote:
> > Maybe signaling the algorithm(s) for which signature(s) are
> > desired/understood would do the trick?
> > I.e. in an EDNS option?
>
> I don't think so. EDNS options relate to servers exchanging DNS messages.
> ZONEMD relates to zones.
>
> Hmm
On Thu, Nov 1, 2018 at 11:52 AM Joe Abley wrote:
> On 1 Nov 2018, at 14:49, Brian Dickson
> wrote:
>
> > So, giving this some tiny bit of thought:
> > When is zonemd added to a response, is that when doing an AXFR?
>
> Construction of ZONEMD RRs and responding to AXFR are orthogonal.
>
>
Right,
On Nov 1, 2018, at 11:49 AM, Brian Dickson
wrote:
> When is zonemd added to a response, is that when doing an AXFR?
Maybe, or maybe when the zone is signed, or maybe when ... It's not clear that
we should be telling zone operators when they have to add this if we want as
many of them to use it
On 1 Nov 2018, at 14:49, Brian Dickson wrote:
> So, giving this some tiny bit of thought:
> When is zonemd added to a response, is that when doing an AXFR?
Construction of ZONEMD RRs and responding to AXFR are orthogonal.
> Maybe signaling the algorithm(s) for which signature(s) are
> desired/
Joe wrote:
> On Nov 1, 2018, at 16:27, Paul Hoffman wrote:
> > The current ZONEMD draft fully supports algorithm agility. What it
> doesn't support is multiple hashes *within a single message*. Having seen
> how easy it is to screw up OpenPGP and S/MIME message processing to handle
> multiple has
On Thu, Nov 1, 2018 at 11:49 AM Paul Hoffman wrote:
> On Nov 1, 2018, at 8:40 AM, Joe Abley wrote:
> >
> > On Nov 1, 2018, at 16:27, Paul Hoffman wrote:
> >
> >> The current ZONEMD draft fully supports algorithm agility. What it
> doesn't support is multiple hashes *within a single message*. Ha
On Nov 1, 2018, at 8:40 AM, Joe Abley wrote:
>
> On Nov 1, 2018, at 16:27, Paul Hoffman wrote:
>
>> The current ZONEMD draft fully supports algorithm agility. What it doesn't
>> support is multiple hashes *within a single message*. Having seen how easy
>> it is to screw up OpenPGP and S/MIME
On Nov 1, 2018, at 16:27, Paul Hoffman wrote:
> The current ZONEMD draft fully supports algorithm agility. What it doesn't
> support is multiple hashes *within a single message*. Having seen how easy it
> is to screw up OpenPGP and S/MIME message processing to handle multiple
> hashes, I think
On Nov 1, 2018, at 8:18 AM, A. Schulze wrote:
>
>
>
> Am 01.11.18 um 00:03 schrieb Wessels, Duane:
>> I think you might be the first person to argue for supporting multiple
>> ZONEMD algorithms per zone. I actually expected more.
>
> I remember Stephen Farrell saying something like "while des
Am 01.11.18 um 00:03 schrieb Wessels, Duane:
> I think you might be the first person to argue for supporting multiple ZONEMD
> algorithms per zone. I actually expected more.
I remember Stephen Farrell saying something like "while designing new
protocols, algorithm agility is an important poin
After some thought, a reasonable way to address this issue is probably:
* Require the sibling address record TTL to be less than the minimum TTL
of the ANAME/CNAME chain (plus some slop so that the polling does not
have to be too frequent), without specifying any particular algorithm.
> On Oct 30, 2018, at 8:27 PM, Mark Andrews wrote:
>
>> On 31 Oct 2018, at 11:16 am, Jim Reid wrote:
>>
>> On 30 Oct 2018, at 22:31, Mark Andrews wrote:
>>>
>>> Ultra frequent key rolls are not necessary. It takes years the latest
>>> releases of name servers to make it into shipping OS’s
On Nov 1, 2018, at 09:08, Richard Gibson
wrote:
RFC 2181 section 5: "It is meaningless for two records to ever have label,
class, type and data all equal - servers should suppress such duplicates if
encountered."
And RFC 7719 section 4 affirms the "different data" requirement.
Excellent.
Joe
On 10/31/18 19:50, Joe Abley wrote:
It sounds wrong to me to say that identical instances of RRs would not be
allowed in a zone.
It's true though, right? It's not meaningful to include more than one resource
record with the same (owner,type, class, TTL, RDATA) in the same RRSet, and
hence al
20 matches
Mail list logo
