of publishing a document saying “key
tags can’t collide” so that future implementer can rely on that, given that
most of the current good implementations already do it?
There are people willing to work on that and there already is running code,
which is more then we have for a lot
Moin!
On 19 Mar 2025, at 5:42, Shumon Huque wrote:
> I spoke to Ralf Weber in-person a bit about this draft -- and Ralf, who is
> clearly not a fan of this draft, is nevertheless fine with letting the
> publication of ns-revalidation proceed in its current form and designation
> (Sta
ttacker is on path between the resolver and the TLD, but not on the path
between the resolver and the zones name server
This IMHO is a too small gain for the complexity re validation adds to the
resolver.
There is nothing in the world other than DNSSEC that will protect
; not doing it. I think this text was put in after consultation with Ralf
> Weber.
Correct and this is the only section of the draft that the Akamai resolvers
comply with in this draft. The draft also mentions ZONEMD and local root,
which supply a better protection for root and the TLD level (as
over TCP use a two
byte length field, for every DNS messages as per RFC1035 4.2.2. One of the
motivators for DELEG was to define a new message format that would allow this,
but for the current DNS message I don’t think that is possible, unless I am
missing something.
So long
-Ralf
that is illegal in that
jurisdiction
- ISP Y has blocked this because it is Malware Command and Control
- You (Or your parents) have selected to not go to social networks
And this is why we need structured errors and possibly a registry for recursive
operat
done their own reputation systems with this,
but we were told that there was no way clients would be getting data from a URL
in a DNS packet.
This draft puts an intermediate layer on it with the registry, which IMHO fixes
this and removes the same domai
uld probably rule out this mechanism
> entirely, since the authenticity of the report cannot be established.
That is what draft-ietf-dnsop-structured-dns-error says in section 5.3 anyway,
and this is an extension of this as I understand it.
So long
-Ralf
——-
Ralf Weber
___
security implications that has and why it was removed.
Given that the draft defines registries for all of that maybe we can come up
with something down the road.
I do like the idea that Stephane brought up of adding a field with a language
tag.
So long
-Ralf
——-
R
me type for a name node. I don’t know a lot about ECH,
but wouldn’t it also make sense to have multiple keys there when you e.g
roll the backend keys and can not do that atomically?
So long
-Ralf
---
Ralf Weber
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
gh
that a small benign change in that code caused a whole array of other
“cornercases” to fail and had to be reverted/rethought.
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
more sustainable.
We have had in recent history a lot of drafts that even were implemented before
they became RFC and had much larger failure ratios. I see no reason to not
immediately implement and RFC that says key tag collisions are not allowed.
So long
-Ralf
——-
Ralf Weber
appropriate. Of course, that's just the view of
> the IETF that does not do flag days.
Hmm I thought if we publish an RFC that updates the DNSSEC RFCs to not allow
keytag collisions I could change my resolver tomorrow and be RFC compliant.
There is no need to wait 20 year
Brian and Petr are right that key collisions should not be allowed.
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
s, but I can see in a multi (dual) signer setup that standby keys
could collide when they made public, but if we are able to threat the multi
signer paths different with DELEG maybe don’t need to care about key collisions
at all, but that is a bit off topic.
So long
oth providers
introduce a key at roughly the same time. So even only allowing one collision
should work.
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
unpredictable for an attacker when a delegation
update will occur.
Hope this clears this up.
So long
-Ralf
---
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
erhauls to handle it.
I agree that future extensions will require code changes, but having a
record type that is extensible from the start might make it easier to
deploy new parameters then it is to do a full RRTYPE, at least that is
the hope.
So long
-Ralf
---
Ralf Weber
_
der has a page here to get more information. It could even
authenticate the domain using DNSSEC or WebPKI.
So long
-Ralf
---
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e relevant experiment, with
clueless delegation I found that the top 10 bad ASes doing something about this
would eliminate the ~80% of the problem, so there could be some gains made
talking to these people if they still appear in your testing now.
So long
-Ralf
---
Ralf Weber
Principal Architec
rowser
could check for not allowing certain UTF characters or maybe having a
reputation list, but that should be a secondary measurement.
So long
-Ralf
---
Ralf Weber
Principal Architect, Carrier Division
Akamai Technologies GmbH
Parkring 20-22, 85748 Garching
phone: +49.89.9400.6174
mobile: +49.151.
luding the
organisation name and then have link to “more information here”?
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
notify/
>
> Some time in the next two weeks, please review this draft to see if you think
> it is suitable for adoption by DNSOP, and send any comments to the list,
> clearly stating your view.
I support adopting this draft and all am willing to review and contribu
lly, but still be able to include the hint and use the extra text if
> it parses correctly.
I agree with Tommy here. It is a nice to have (MAY/SHOULD) rather than a “MUST”
as it currently is stated in the draft.
So long
-Ralf
——-
Ralf Weber
you please explain it in more detail. From my
understanding it just is a format for the EXTRA-TEXT field and if they client
does not parse or understand it, it still can be displayed or used for
debugging.
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailin
1] to
elicit the Extended DNS Error option in the DNS response.
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
would be good to have a bigger sample size, maybe including
what software actually runs the service (which might be custom for some public
resolvers).
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
r UDP and packets are getting dropped
anywhere in the network for different reasons, so confusing this with a clearly
visible configuration error would be wrong.
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
of an URN scheme works, can you elaborate how this
works? Are there requirements for the third parties?
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
that information can be conveyed to the
end user. The EDE categories are rather broad and hence don’t give enough
information on why exactly a site is blocked. Now we could also use free
text, which is a problem for people operating in multi language environments
or let each resolver operator pick t
Moin!
On 28 Mar 2023, at 10:14, Mark Andrews wrote:
> Is this JST?
Yes. Currently UTC+9. So it is 04:00 UTC
So long
-Ralf
>
>> On 28 Mar 2023, at 11:15, James Mitchell wrote:
>>
>> Hello,
>> The Root Zone Algorithm Rollover Study Design Team is hosting a public
>> session at IETF 116 and in
any auth.
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
relevant ADs and the full IESG.
>
> However, before doing all this, I'd like to confirm that the WG doesn't
> object to the plan….
I agree with this plan and as SVCB is already widely deployed and we need an
RFC to point to and not a draft to get people not doing stupid things
should be 0 going forward.
So long
-Ralf
---
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
IMHO has value even if the number is not big.
We all know that a lot of data in the DNS is garbage, that should not
stop us from using the good data.
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: February 5th, 2023
>
> Thanks,
> tim wicinski
> For DNSOP co-chairs
> ___
> DNSOP mailing l
concerns initially and my stance has not changed. So if this
becomes and RFC it can’t be more then informational or experimental.
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
the requirements for including glue in zone data, beyond
> those given in [@!RFC1034] and [@!RFC1035].
Yeah that looks fine to me. The main point was to make sure that zone
data can also be a cause of failed/false referral. This text addresses
this.
So long
-Ralf
——-
Ralf Weber
___
/* answer = false; */
Well maybe the out of the box 9.16.1-Ubuntu that my distribution (Ubuntu 20.04
LTS) gave me either patched these or changed the default configuration to not
fail as I did nothing else then adding a zone to the config and it loaded.
So long
-R
Moin!
On 22 Mar 2022, at 14:43, Hugo Salgado wrote:
> On 14:02 22/03, Ralf Weber wrote:
>> However missing data might make it impossible for a name server to answer
>> with the correct (referral) glue data.
>>
>> And maybe add some encouragement or referral ;-)
missing data might make it impossible for a name server to answer with
the correct (referral) glue data.
And maybe add some encouragement or referral ;-) to work that has to be done
elsewhere.
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP
requirement sound avoid term
> "negative" caching. In my eyes it is a bit misleading because "negative" is
> typically used for different kinds of answers.
Maybe failed resolution caching is a better term here.
So long
-Ralf
——-
Ralf Weber
___
l
sibling glue to make it fit that is fine also. There is authoritative software
out there that has a minimize-responses setting to allow the operator to define
that behaviour.
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Moin!
On 28 Jul 2021, at 18:03, Paul Wouters wrote:
> On Wed, 28 Jul 2021, Ralf Weber wrote:
>>> First, as Mark said, sibling glue is sometimes needed.
>> It is only needed for broken circular dependancies, which we don’t care
>> about.
>
> They are not broken u
Moin!
On 28 Jul 2021, at 5:10, Paul Wouters wrote:
On Wed, 28 Jul 2021, Ralf Weber wrote:
However requiring authorities to put unnecessary data in the
additional section
(the sibbling glue) is not something I support.
First, as Mark said, sibling glue is sometimes needed.
It is only
itative server
to add this record type to signal an empty non terminal responses?
So long
-Ralf
—--
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e) is not something I support.
So ong
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ecord type instead of using TXT, and IMHO
this draft follows this advice (both the RR and size recommendations).
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
nhancements in the future.
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Moin!
On 20 May 2021, at 3:32, Brian Dickson wrote:
> (There's a reason I'm not suggesting making SVCB non-extensible, or
> touching any aspect of the SVCB thing itself.)
>
> Note that more ALPN values are supported, and how those are
> defined/used/etc are really not relevant to the structure (wi
her
straw
on the camels back IMHO.
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
TS has already shown that. DNS being an
distributed mechanism is far better suited as it does not require an
update of the end device.
Just my .02 cents as a DNS guy ;-).
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ie
cribe these deployments, so that we can
discuss them go ahead. But I don’t think that we want to require DNS being
build that way.
So long
-Ralf
—--
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
is suitable for
adoption
by DNSOP, and comments to the list, clearly stating your view.
I support adaption, will review and may contribute text.
So long
-Ralf
—--
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Moin!
On 14 Apr 2020, at 17:59, Paul Vixie wrote:
Ralf Weber wrote on 2020-04-14 08:57:
Just to clarify if I understand that correct. The DS for example.net
would be example._dnssec.net DS. Correct? So would you propose to do
example._ns2.net NS2 to distinguish parent and child NS2 records
DS, it should have been example._dnssec.com
DS.
Just to clarify if I understand that correct. The DS for example.net
would be example._dnssec.net DS. Correct? So would you propose to do
example._ns2.net NS2 to distinguish parent and child NS2 records?
So long
-Ralf
—--
Ralf Weber
use of the rare cases this
appears, see TC as the right solution as it is simple and backwards
compatible. EDE already is complex we should not increase it complexity
for a rare corner case.
So long
-Ralf
—--
Ralf Weber
___
DNSOP mailing list
DNSO
hat they do will not create
interoperable solutions.
So long
-Ralf
——-
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
lem of auto discovery of DoH servers which is one of the cases that
can be solved by this draft (when enhanced appropriately)
So long
-Ralf
—--
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ave to use the DNS reverse tree for the names, even
though only a tiny percent of that tree will be signed.
Well DNSSEC signing might work with the proper resolver signing reverse
for RFC1918 which is a very common case will not work.
SO long
-Ralf
—--
Ralf Weber
___
Moin!
On 30 Jun 2019, at 1:01, Paul Hoffman wrote:
- The draft offers two methods of retrieving the object but says
nothing about which is mandatory (Me being a lazy DNS geek will
certainly not put a web server on my DNS server so won’t implement
3). Will it still work? Why?
Neither is mand
) this query and either forward or answer by himself. DNS
Proxies might not implement RFC3597. Should there be a fallback (TXT)?
So long
-Ralf
—--
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ion.
Why? They are the same that are in the answer section and for DNSSEC
the signed ANAME is important and not the unsigned addresses or am I
missing something?
So long
-Ralf
—--
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
sailed.
And I’ll read the document and comment on it later…
So long
-Ralf
—--
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
is never was fully true and with more and more bring your on device
requiring this will get harder, so network providers (ISP, enterprises,
my home network ;-) have to have tools to apply their network rules,
or if people don’t want to play by the rules block them.
So long
-Ralf
—--
Ralf Weber
_
Moin!
On 14 Mar 2019, at 10:53, Stephen Farrell wrote:
On 14/03/2019 14:41, Ralf Weber wrote:
the DoH protocol caused some application providers to experiment with
switching resolution per default away from OS and the local network
provider
I wasn't aware that some application provide
people might have planned there schedule around that it should be the
place. I also think Paul and others have engaged constructive in the
discussion about the topic.
So long
-Ralf
—--
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https
switch
a basic internet function (name lookups) without the users consent which
are due to using HTTPs/443 harder to block for enterprises. It is a
pretty clear difference.
So long
-Ralf
—--
Ralf Weber
___
DNSOP mailing list
DNSOP@ietf.org
https
gone. Now IMHO we should work on getting these rates
where fragments are dropped down and not implement yet another
workaround.
Ralf Weber: Having one v6 name server that will respond correct with
fragments also solves the problem. I think the problem space is to
narrow to burden this problem
occur if all name
servers are on v6. Having one v6 name server that will respond correct
with fragments also solves the problem. I think the problem space is to
narrow to burden this problem on all resolvers.
So long
-Ralf
—--
Ralf Weber
___
DNSOP
Moin!
As the mic line was closed after Mark, and I didn’t have anything new
to say meaning I support the draft but don’t like the EDNS options
before Mark spoke I use email to comment on Marks comments.
We already have a mechanism where the Authority tells the resolver how
long to cache stuf
Moin!
On 17 Aug 2017, at 0:09, Lanlan Pan wrote:
> Yes, I agree, in fact the *online cache rate* is small (0.12% queries), LRU
> & TTL works fine.
> SWILD not save many online cache size, because of the queries rate.
> And Temporary Domain Names/ All Names: 41.7% for 7 days statistics, the
> rate
Moin!
On 16 Aug 2017, at 6:19, Lanlan Pan wrote:
We analyzed our recursive query log, about 18.6 billion queries from
12/01/2015 to 12/07/2015.
We found about 4.7 Million temporary domains occupy the recursive's
cache,
which are subdomain wildcards from Skype, QQ, Mcafee, Microsoft,
360safed
Moin!
On 16 Aug 2017, at 2:44, Warren Kumari wrote:
>> If it's a commonly-used name, I suspect the more straightforward
>> "prefetching" should suffice in practice:
>> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-hammer/
>> Several popular recursive servers already implement the feature.
>
Moin!
On 10 Mar 2017, at 19:15, Shumon Huque wrote:
> I would like to see us deploy an authenticated denial of existence
> mechanism that is not eminently susceptible to offline dictionary
> attack. My experience so far is that most people in the crypto
> community do not look favorably on NSEC3.
Moin!
On 7 Jan 2017, at 23:54, Scott Schmit wrote:
why you think hostile actors will do things with RPZ that they
couldn't do now?
>
> For the very reasons that the authors want to make this an RFC -- RPZ
> isn't interoperable between DNS resolvers today. Once this RFC is
> published, i
Moin!
On 21 Dec 2016, at 15:36, william manning wrote:
> the complaints about operator participation in the IETF go back decades.
> no news there.
So you don't want operator participation in the IETF?
> in fact, there are operator driven fora for just such activities, DNS-OARC
> comes to mind.
D
Moin!
On 20 Dec 2016, at 17:33, Paul Hoffman wrote:
On 20 Dec 2016, at 7:16, tjw ietf wrote:
Please review this draft to see if you think it is suitable for
adoption by
DNSOP, and comments to the list, clearly stating your view.
The draft itself is really not suitable for adoption by the W
Moin!
On 19 Dec 2016, at 8:28, ac wrote:
On Mon, 19 Dec 2016 07:53:42 +0100
"Ralf Weber" wrote:
So if this is the IP of a phishing site or the IP of an command and
control host that tells its bot to execute criminal action you still
valid the accuracy of the answer higher then possi
Moin!
On 19 Dec 2016, at 6:05, ac wrote:
> On Sun, 18 Dec 2016 23:45:34 +
> "Adrien de Croy" wrote:
>>> If the admin's goal is to block access to malicious sites, then
>>> they want to block the traffic, not falsify DNS. If the goal is
>>> to warn users away from bad places, they can publis
Moin!
On 17 Dec 2016, at 20:25, David Conrad wrote:
I presume NSEC Aggressive Use will significantly reduce the amount of
crap hitting the root servers.
There are other ways of reducing the crap to the root servers (RFC
7706). I don't think NSEC Agressive use will reduce crap a lot as if I
re
Moin!
On 15 Oct 2016, at 10:22, Mikael Abrahamsson wrote:
set up a domain with a algorithm ID nobody will ever implement
(reserve it if need be), and check that this domain returns as
unvalidated (as per SHOULD in the RFC).
Geoff Houston did some research here some years ago and just did an
u
Moin!
On 28 Sep 2016, at 17:21, Shumon Huque wrote:
> To be precise, I would say we are not necessarily always pruning out entire
> zones. For a leaf zone, we are pruning all names within that zone below the
> nxdomain-cut, modulo cached entries, i.e. a subset of the zone. But yes,
> for non-leaf
Moin!
On 20 Jul 2016, at 14:36, 延志伟 wrote:
But anyway, let's go back to the scenario considered by our draft to
illustrate its necessity.
I show an example as following (although I think we have described it
several times. :-)):
In order to visit the www.baidu.com, the user has to query
www.ba
Moin!
On 20 Jul 2016, at 7:34, 延志伟 wrote:
I understand your points, but these risks always be there because DNS
response is larger than the request, like DNSSEC.
Yes, which is why we have several proposals on how to mitigate the
problem by e.g not giving back ALL qtypes to an ANY question, or
Moin!
On 20 Jul 2016, at 5:03, 延志伟 wrote:
About the DDoS risk, it should not be worried so much because this
scheme is controlled/triggered by the recursive server (with a flag as
NN bit).
In other words, the recursive server can get the piggybacked multiple
responses only when it wants and o
Moin!
On 19 Jul 2016, at 9:00, Christopher Morrow wrote:
> On Jul 19, 2016 8:36 AM, "Ralf Weber" wrote:
>>
>>
>> Except that if you have a decent size and hot Cache with refreshing
>> these records will be in there anyway. IMHO you gained nothing, but I
&g
Moin!
On 19 Jul 2016, at 8:18, George Michaelson wrote:
> "in reality" is skewing the story. You don't foresee a usecase, but
> you do foresee abuse? So deploy cookies or move to TCP, or DTLS or
> some other cost space where amplify implies special knowledge, or cost
> on the amplifier.
Which the
Moin!
You were not alone, though I hummed for different reasons. I think it is
bad to blow up responses with stuff that might be helpful, but in reality
only will be helpful to people running amplification attacks.
So long
-Ralf
___
DNSOP mailing list
Moin!
On 15 Mar 2016, at 15:16, Shumon Huque wrote:
> More generally, it also reduces demands on authoritative servers by
> not sending them a set of unnecessary queries.
>
> I have not viewed this as a 'speed hack', or in fact any hack, but as a
> way to make the entire DNS ecosystem more efficie
Moin!
On 8 Feb 2016, at 9:57, Jakob Schlyter wrote:
At this point, we're seeking more public comments - on this mailing
list (unless the chairs disapproves), on the our issue tracker [4] or
via email to the authors.
Thanks a lot for this work. I certainly would like dnsop to work on
this.
I
Moin!
On 22 Dec 2015, at 23:39, George Michaelson wrote:
> I want to dispute one part of this: the "DNSSEC may not scale well" part.
> With thanks to Ray Bellis, APNIC has been running an evldns webserver which
> signs on the fly, and we have achieved north of 3000 signs/second from this
> code o
Moin!
On 8 Nov 2015, at 0:52, Mark Andrews wrote:
> Fixing misimplementations of the protocol is different to fixing
> misconfiguration of servers. The draft is aimed primarially at
> fixing misimplementations rather than misconfigurations though both
> need fixing.
Sorry I over generalised. To
Moin!
On 7 Nov 2015, at 18:20, Antoin Verschuren wrote:
But that’s not the point.
The point is that we need consensus on criteria for what is good and
what is bad DNS(SEC).
Isn't that what the RFCs describe. Is there really a point where someone
disagrees?
I agree with you that there is no i
Moin!
On 6 Nov 2015, at 21:17, Mark Andrews wrote:
In message <8d78b784-34d3-421e-b82c-52dd32e22...@fl1ger.de>, "Ralf
Weber" write
s:
Really TLDs doing repeated checks? I know some do when you
register domains, but repeatedly? Examples?
Yes. Daily checks of all delegated
Moin!
On 6 Nov 2015, at 18:50, Antoin Verschuren wrote:
Op 6 nov. 2015, om 08:46 heeft Ralf Weber het volgende
geschreven:
Really TLDs doing repeated checks? I know some do when you
register domains, but repeatedly? Examples?
.nl f.e.
Registrars get a monthly report on DNS errors with
Moin!
This may be totally in appropriate
On 6 Nov 2015, at 0:54, Mark Andrews wrote:
> I keep getting told the IETF can't tell people what to do
> but that is *exactly* what we do do when we issue a BCP.
> We tell people what best current practice is and ask them
> to fol
Moin!
On 5 Oct 2015, at 17:42, Suzanne Woolf wrote:
All,
First, thanks to the engaging on this.
On Oct 5, 2015, at 5:20 PM, "Joe Abley" wrote:
Perhaps it's time to sit back and wait for others here to express an
opinion.
I'd like to hear opinions from others in the WG with an operationa
Moin!
On 5 Aug 2015, at 22:32, Stephane Bortzmeyer wrote:
> On Tue, Aug 04, 2015 at 06:15:43PM -0400,
> Ted Lemon wrote
> a message of 312 lines which said:
>
>> because the client may be an open resolver that implements cookies,
>> and indeed open resolvers that implement cookies will now be
>>
1 - 100 of 158 matches
Mail list logo
