On Wed, 7 Feb 2018, Robert Story wrote:
On Wed 2018-02-07 10:43:16-0500 Paul wrote:
How about using this query to also encode an
uptime-processstartedtime value? Maybe with accurancy reduced to
minutes. I think that would return valuable data.
-1 for feature creep and the technical reasons Jo
>
> Fine. Now we need to have something actionable, e.g. set of names for
> Geoff to test.
The first test I’ve undertaken is to test two name forms in an ad campaign over
the past few days:
heres an example of the test:
xm--u82aa292f-c13-s1518066940-i
_xm_-u82aa292f-c13-s1518066940-i0
On Wed 2018-02-07 10:43:16-0500 Paul wrote:
> How about using this query to also encode an
> uptime-processstartedtime value? Maybe with accurancy reduced to
> minutes. I think that would return valuable data.
-1 for feature creep and the technical reasons Joe mentioned.
Maybe we need a SNMP over
> On 8 Feb 2018, at 9:43 am, Mark Andrews wrote:
>
> Software that processes CAA records returned by the DNS can remove
> any duplicates detected at that level of processing. The DNS isn’t
> in a position to do that de-duplication.
>
> For UPDATE I would always delete the CAA RRset and re-add i
> On 8 Feb 2018, at 9:15 am, 神明達哉 wrote:
>
> At Thu, 8 Feb 2018 08:25:35 +1100,
> Mark Andrews wrote:
>
>>> I happen to have this question while reading RFC6844: what does the
>>> "matching" mean in the following description of Section 5.1?
>>>
>>> Tag: The property identifier, a sequence o
At Thu, 8 Feb 2018 08:25:35 +1100,
Mark Andrews wrote:
> > I happen to have this question while reading RFC6844: what does the
> > "matching" mean in the following description of Section 5.1?
> >
> > Tag: The property identifier, a sequence of US-ASCII characters.
> >
> > Tag values MAY c
> On 8 Feb 2018, at 3:26 am, 神明達哉 wrote:
>
> I happen to have this question while reading RFC6844: what does the
> "matching" mean in the following description of Section 5.1?
>
> Tag: The property identifier, a sequence of US-ASCII characters.
>
> Tag values MAY contain US-ASCII chara
> On Feb 7, 2018, at 6:13 AM, Benno Overeinder wrote:
>
> On 07/02/2018 10:12, Warren Kumari wrote:
>> Whoops, last message was blank; finger fail.
>>
>>
>> On Wed, Feb 7, 2018 at 3:57 AM, Warren Kumari wrote:
>>> On Wed, Feb 7, 2018 at 2:15 AM, Petr Špaček wrote:
Fine. Now we nee
I happen to have this question while reading RFC6844: what does the
"matching" mean in the following description of Section 5.1?
Tag: The property identifier, a sequence of US-ASCII characters.
Tag values MAY contain US-ASCII characters 'a' through 'z', 'A'
through 'Z', and the nu
Hi Paul,
> On Feb 7, 2018, at 10:43, Paul Wouters wrote:
>
>
> I think it is useful to know how long the DNS resolver process has been
> up, and/or how long the server running the DNS resolver has been up,
> when it is sending the sentinel queries.
>
> That would allow us to detect if we are l
On Feb 7, 2018, at 9:22 AM, Stephane Bortzmeyer wrote:
> The intention of this specification is to enable stateful information
> (connection parameters and DNS data) directly related to the DSO
> Session to be transmitted. This creates trackable state and prevents
> queries from coming from succes
I think it is useful to know how long the DNS resolver process has been
up, and/or how long the server running the DNS resolver has been up,
when it is sending the sentinel queries.
That would allow us to detect if we are looking at spun up server
instances and/or provisioned containers with old
On Wed, Feb 7, 2018 at 6:13 AM, Benno Overeinder wrote:
> On 07/02/2018 10:12, Warren Kumari wrote:
> > Whoops, last message was blank; finger fail.
> >
> >
> > On Wed, Feb 7, 2018 at 3:57 AM, Warren Kumari wrote:
> >> On Wed, Feb 7, 2018 at 2:15 AM, Petr Špaček wrote:
> >>>
> >>> Fine. Now we
People here will certainly have ideas for our SAAG colleagues.
--- Begin Message ---
(This is related to this draft:
https://tools.ietf.org/html/draft-foudil-securitytxt-02)
The proposed "security.txt" file has a matching optional
"security.txt.sig" file. One of the common issues we have received
On Thu, Feb 01, 2018 at 02:14:53PM -0500,
tjw ietf wrote
a message of 55 lines which said:
> This starts a Working Group Last Call for draft-ietf-dnsop-session-signal
After reading -05 :
My personal feeling is that it is complicated, with a lot of
details. May be separating in two documents,
On 07/02/2018 10:12, Warren Kumari wrote:
> Whoops, last message was blank; finger fail.
>
>
> On Wed, Feb 7, 2018 at 3:57 AM, Warren Kumari wrote:
>> On Wed, Feb 7, 2018 at 2:15 AM, Petr Špaček wrote:
>>>
>>> Fine. Now we need to have something actionable, e.g. set of names for
>>> Geoff to te
Whoops, last message was blank; finger fail.
On Wed, Feb 7, 2018 at 3:57 AM, Warren Kumari wrote:
> On Wed, Feb 7, 2018 at 2:15 AM, Petr Špaček wrote:
>>
>>
>> On 6.2.2018 17:13, Paul Hoffman wrote:
>>> On 6 Feb 2018, at 8:04, Petr Špaček wrote:
>>>
On 6.2.2018 13:22, Tony Finch wrote:
>>>
On Wed, Feb 7, 2018 at 2:15 AM, Petr Špaček wrote:
>
>
> On 6.2.2018 17:13, Paul Hoffman wrote:
>> On 6 Feb 2018, at 8:04, Petr Špaček wrote:
>>
>>> On 6.2.2018 13:22, Tony Finch wrote:
A. Schulze wrote:
>
> Yes, "kskroll-sentinel-is-ta-" is more descriptive and specific.
> I
18 matches
Mail list logo