Mark Andrews writes:
> > Yes, and that's where I see a problem: when the software doesn't know
> > the agreement has been severed.
>
> Presumably you won’t get back a server tag and you can log that.
No you may get back a server tag, and you're equally as likely to
misinterpret it just as the
On Mon, Mar 4, 2019 at 11:00 PM Paul Wouters wrote:
> On Tue, 5 Mar 2019, Mark Andrews wrote:
>
> >> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
> >>> can I ask, what happens when a domain is intentionally down though? For
> >>> instance, take .eg... ~4yrs back? (maybe 5?)
> On 5 Mar 2019, at 2:59 pm, Paul Wouters wrote:
>
> On Tue, 5 Mar 2019, Mark Andrews wrote:
>
>>> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
can I ask, what happens when a domain is intentionally down though? For
instance, take .eg... ~4yrs back? (maybe 5?)
On Tue, 5 Mar 2019, Paul Hoffman wrote:
This makes me very nervous. An edge ISP DNS server could use this to
mark DNS packets from certain users, and applications could use this as
another cookie to track users, especially in light of endusers talking
directly to open resolvers like the Quads,
On Tue, 5 Mar 2019, Mark Andrews wrote:
On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
can I ask, what happens when a domain is intentionally down though? For
instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
master/shadow NS go down, hard. All public
> On 5 Mar 2019, at 1:26 pm, Paul Vixie wrote:
>
> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
>> can I ask, what happens when a domain is intentionally down though? For
>> instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
>> master/shadow NS go down,
On Mon, Mar 4, 2019 at 9:26 PM Paul Vixie wrote:
> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
> > can I ask, what happens when a domain is intentionally down though? For
> > instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
> > master/shadow NS go down,
On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
> can I ask, what happens when a domain is intentionally down though? For
> instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
> master/shadow NS go down, hard. All public auth servers eventually (in a
> day or
can I ask, what happens when a domain is intentionally down though? For
instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
master/shadow NS go down, hard. All public auth servers eventually (in a
day or so) went dark too.
If someone is 'ordered' to make a zone dark, there may
On Mar 4, 2019, at 5:44 PM, Paul Wouters wrote:
>
> On Mon, 4 Mar 2019, Ray Bellis wrote:
>
>> This new draft describes a way for clients and servers to exchange a limited
>> amount of information where the semantics of that information are completely
>> unspecified, and therefore determined
On Mon, 4 Mar 2019, Ray Bellis wrote:
This new draft describes a way for clients and servers to exchange a limited
amount of information where the semantics of that information are completely
unspecified, and therefore determined by bi-lateral agreement between the
client and server
On Tue, 5 Mar 2019 at 00:45, Mark Andrews wrote:
8<
Presumably you won’t get back a server tag and you can log that.
>
Not always.
The spec does not require the server to return a server tag in response to
a client tag.
However, a server tag may only be returned in response to a request
Ah yes. "imminent" was a reminder of their commitment to volunteer to give
feedback :)
If we do another rev as a result of this call, I'll remove it. Otherwise,
I'll leave a note with the RFC Editor to do so.
Paul
On Mon, Mar 4, 2019 at 7:40 PM Michael Sinatra
wrote:
> Section 8 -
On Mon, 4 Mar 2019 at 23:43, Wes Hardaker wrote:
> Dick Franks writes:
>
> > As the man said, "[semantics are] determined by bi-lateral agreement".
> > If the counter-party decides to do something different, it has
> repudiated the
> > agreement.
>
> Yes, and that's where I see a problem: when
> On 5 Mar 2019, at 10:43 am, Wes Hardaker wrote:
>
> Dick Franks writes:
>
>> As the man said, "[semantics are] determined by bi-lateral agreement".
>> If the counter-party decides to do something different, it has repudiated the
>> agreement.
>
> Yes, and that's where I see a problem:
DNSOP,
Thanks to the great feedback, we were able to update the document to better
match the preferences of the working group and address the outstanding concerns.
To summarize the changes:
Add missing reference (Stuart Cheshire)
Modify presentation format of date/time to match RRSIG (Mark
Section 8 - Acknowledgements:
"We wish to thank Michael Sinatra, Roland van Rijswijk-Deij, Olafur
Gudmundsson, Paul Hoffman and Evan Hunt for their imminent feedback."
Paraphrasing one of my colleagues, is the part about "imminent feedback"
a prediction, or a hint that we are supposed to give
Dick Franks writes:
> As the man said, "[semantics are] determined by bi-lateral agreement".
> If the counter-party decides to do something different, it has repudiated the
> agreement.
Yes, and that's where I see a problem: when the software doesn't know
the agreement has been severed.
--
Wes
On Mon, 4 Mar 2019 at 23:03, Wes Hardaker wrote:
> Ray Bellis writes:
>
> > This new draft describes a way for clients and servers to exchange a
> > limited amount of information where the semantics of that information
> > are completely unspecified, and therefore determined by bi-lateral
> >
Ray Bellis writes:
> This new draft describes a way for clients and servers to exchange a
> limited amount of information where the semantics of that information
> are completely unspecified, and therefore determined by bi-lateral
> agreement between the client and server operators.
Hmmm..
You specify a well known TSIG key (e.g. name=“.”, algorithm=hmac-sha256,
key=<32-zero-bytes>)
then you use it when you don’t have a more specific key. If the server support
the WKK you
will get back a TSIG signed response that can’t have been forged by a off path
attacker if it
matched the
On Mar 4, 2019, at 1:47 PM, Paul Hoffman wrote:
> Yes: the DNS state specification is necessarily complicated to implement
> because it is doing much more than what is proposed here. It is OK for
> someone to propose a simple mechanism for a simple need.
No argument, just curious if this had
At Mon, 04 Mar 2019 20:43:14 +0900 (JST),
fujiw...@jprs.co.jp wrote:
> > - Section 3
> >
> >Linux 2.6.32, Linux 4.18.20
> >and FreeBSD 12.0 accept crafted "ICMPv6 Packet Too Big" packet and
> >path MTU decreased to 1280.
> >
> > I suspect this often doesn't matter much in practice.
On Mar 4, 2019, at 10:06 AM, Ted Lemon wrote:
>
> On Mar 4, 2019, at 11:27 AM, Ray Bellis wrote:
>> This new draft describes a way for clients and servers to exchange a limited
>> amount of information where the semantics of that information are completely
>> unspecified, and therefore
On Mar 4, 2019, at 11:27 AM, Ray Bellis wrote:
> This new draft describes a way for clients and servers to exchange a limited
> amount of information where the semantics of that information are completely
> unspecified, and therefore determined by bi-lateral agreement between the
> client and
On Mar 4, 2019, at 8:27 AM, Ray Bellis wrote:
> This new draft describes a way for clients and servers to exchange a limited
> amount of information where the semantics of that information are completely
> unspecified, and therefore determined by bi-lateral agreement between the
> client and
On Mon, Mar 4, 2019 at 11:05 AM Paul Wouters wrote:
> On Mon, 4 Mar 2019, Warren Kumari wrote:
>
> > So, my plan is to 1: ask the authors to please swap the Y to an N as
> below and 2: progress the document with the hope that this
> > section will survive the publication process.
>
> But I do
DNSOP,
This new draft describes a way for clients and servers to exchange a
limited amount of information where the semantics of that information
are completely unspecified, and therefore determined by bi-lateral
agreement between the client and server operators.
There are known cases where
On Mon, 4 Mar 2019, Warren Kumari wrote:
So, my plan is to 1: ask the authors to please swap the Y to an N as below and
2: progress the document with the hope that this
section will survive the publication process.
But I do not hope that.
The March telechats are often really full - ADs
Hi Warren,
On 4 Mar 2019, at 16:23, Warren Kumari wrote:
On Thu, Feb 28, 2019 at 10:13 AM Peter van Dijk
wrote:
As this pertains to a section that will apparently be removed for
publication, only posting it here on dnsop@ for historical reasons:
So, RFC7942 (the one about "The
On Thu, Feb 28, 2019 at 10:13 AM Peter van Dijk
wrote:
> On 13 Feb 2019, at 20:29, The IESG wrote:
>
> > The IESG has received a request from the Domain Name System Operations
> > WG
> > (dnsop) to consider the following document: - 'Algorithm
> > Implementation
> > Requirements and Usage
> From: Mark Andrews
> Or one can use TSIG with a well known key to get a cryptograph hash of the
> response. Below is how
> how the servers for the Alexa to 1 Million handle unexpected TSIG. It’s well
> under a day to add
> this to a recursive server that supports TSIG already. It’s a
> From: 神明達哉
>>https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-01
>>
>> It summarized DNS cache poisoning attack using IP fragmentation
>> and countermeasures.
>>
>> If the draft is interested, I will request timeslot at IETF 104.
>
> I've read the draft. I think it's
33 matches
Mail list logo
