On 4 Nov 2020, at 2:11, Wes Hardaker wrote:
"Andrew McConachie" writes:
I’m having a hard time understanding the two proposed deployments
in
this document.
It's not as clean as I'd like, certainly. I was pushing up against
the
draft submission deadlines and didn't get all the wording
If an attacker is spoofing responses, it seems that they could send a
different NS and A record, and a new calculated DS hash. So this provides
no protection against spoofing?
We would need instead (or in addition) an RRSIG record to actually protect
this.
An example would help.
--
Bob Harold
"Andrew McConachie" writes:
> 1. Is a special-use domain per [RFC6761], and does not (and will never)
> exist in the GID.
> In this document, we refer to this as ".internal" for discussion purposes
> only following
> conventions in [draft-wkumari-dnsop-internal].
>
> I read the above
On 4 Nov 2020, at 17:47, Wes Hardaker wrote:
"Andrew McConachie" writes:
1. Is a special-use domain per [RFC6761], and does not (and will
never) exist in the GID.
In this document, we refer to this as ".internal" for discussion
purposes only following
conventions in [draft-wkuma
Hi all,
There is currently no streamlined way for recursive resolver operators to
distribute the IP ranges/locations that their server farm may use. It is
currently a mixture of csv files shared over email, or web pages with
formats that may be unique to each provider and rarely directly parseable
Thanks for the work on this, Stephane, Ralph, and Paul.
Could you please clarify explicitly what should happen in the case of
encountering CNAMEs? Or DNAMEs?
The way I read it, at least for CNAMEs, is that you just keep
prepending labels to the ANCESTOR name so encountering the CNAME is in
pract
One problem with DiS is that assumes that address records in the additional
section *always* come from the delegating zone (see how the hash is created).
This is not how DNS works. Address records can, correctly, come from other
sources, even when the name is *below* the zone cut.
Take a server t
> From: Bob Harold
> If an attacker is spoofing responses, it seems that they could send a
> different NS and A record, and a new calculated DS hash. So this provides
> no protection against spoofing?
>
> We would need instead (or in addition) an RRSIG record to actually protect
> this.
Thanks
> From: Mark Andrews
> One problem with DiS is that assumes that address records in the additional
> section *always* come from the delegating zone (see how the hash is created).
> This is not how DNS works. Address records can, correctly, come from other
> sources, even when the name is *below*
> On 5 Nov 2020, at 15:49, fujiw...@jprs.co.jp wrote:
>
>> From: Mark Andrews
>> One problem with DiS is that assumes that address records in the additional
>> section *always* come from the delegating zone (see how the hash is created).
>> This is not how DNS works. Address records can, corr
10 matches
Mail list logo
