hey are doing. Recent DDoS stats indicate that redirected DNS over UDP is no
longer a significant source in real-world attacks. Short of being fodder for
yet another "UDP considered harmful" discussion, why even note this?
--Paul Hoffman
___
dns-
is not worth it.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
nd
of this year.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
For all the people on this list who are taking a keen interest in priming:
there is a call in the DNSOP WG about whether draft-klh-dnsop-rfc8109bis should
be adopted as a WG item. This thread has brought up some topics related to
priming that are not covered in RFC 8109.
--Paul Hoffman
x27;d) or someone you might know on SSAC.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Even worse! Thanks.
--Paul
smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
t; The next update of firefox and hopefully chromium based browsers (sept 26),
> should contain the updated list.
> The only browser we could not find any documentation on this matter is
> Apple's safari.
> p.s It has nothing to do with right to left scripts.
Whew! That's very
sing another ccTLD IDN such as xn--4gbrim works fine. Firefox works correctly
when you enter the non-existent "nic.xn--4dbrk0ce", but Safari and Chrome fall
back to search. All three work fine when entering the non-existent
"nic.xn--4gbrim".
--Paul Hoffman
smi
https://sam.gov/opp/93a697c39c3f44839a2000119c3e4956/view
(tl;dr: US is soliciting bids for being the back-end for .gov)
smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://li
t", whith the nsswitch code sending no A/ DNS queries for
> TLDs. Only /etc/hosts and other local sources would be consulted.
Advocating that a library not check for valid data (even if you believe that it
is "profoundly fragile" seems more likely to lead to damage than ch
To date, have any of your customers or anyone in the DNS community, supported
your choice of how to implement this? If not, or if only a trivial number have,
does that affect your decision on how to implement this?
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
ervers)
was discussed in DNSOP earlier this year.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
in advance!
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
it is not a
requirement.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
te leaks almost insignificant; given the low rate of DNSSEC
validation, any impersonation can be quite important.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
htt
root
instance inside or outside of $country would reply to a query for
"d.ns.facebook.com" with a referral, not an answer. Thus, if you are sending
that query to one of the IP addresses for $x.root-servers.net and you get an A
record back, the host you are hitting is not run by one o
qualified
contractors to choose from. If you work for such a contractor, please note the
deadlines listed in the overview. If you know someone who works for such a
contractor, please tell them about this RFP. Thanks in advance!
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic
n summary, it is fine to propose that software default to issuing larger RSA
keys for ZSKs, but not with an analysis that makes a lot of unstated guesses.
Instead, it is fine to say "make them as large as possible without causing
automatically needi
no one has. As far as I can tell, no one has even tried.
--Paul Hoffman (who pulled getdns together, contracted by Google)
smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https:
OK, I know this is trivial, but:
> bbn.com 93451500
Stephen Kent. Just sayin'
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.n
ore it again until it comes up again fiveish years from now.
Any attempted update to RFC 4035 will cause some people to squawk even if it
makes the intent clearer.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
dns-operati
On Feb 28, 2021, at 11:35 AM, Vladimír Čunát wrote:
>
> On 2/28/21 3:24 AM, Paul Hoffman wrote:
>> On Feb 27, 2021, at 5:32 PM, Mark Andrews
>> wrote:
>>
>>> It says that RRSIGs exist at that name.
>>>
>> Could you say more? I don't
On Feb 27, 2021, at 5:32 PM, Mark Andrews wrote:
>
> It says that RRSIGs exist at that name.
Could you say more? I don't understand the context here.
For example, "dig @f.root-servers.net -4 nl rrsig" gives a reply with no Answer
section.
--Paul Hoffman
smime.p7
are, configurations, or in a clarification to RFC 4035), but
the differing responses between RSOs with the same zone file seems worthy of
discussion.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dn
t;dig @8.8.8.8 +dnssec +yaml {} A".format(this_name),
shell=True, capture_output=True, encoding="utf-8", check=True)
Given the errors, I had to add the +noidnout option.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
On Jan 5, 2021, at 12:41 PM, John Levine wrote:
>
> In article <853ece14-271f-4e93-9473-d1dbde836...@icann.org> you write:
>> On Jan 5, 2021, at 11:20 AM, Dave Lawrence wrote:
>>>
>>> Paul Hoffman writes:
>>>> I am using tools that expect host
On Jan 5, 2021, at 11:20 AM, Dave Lawrence wrote:
>
> Paul Hoffman writes:
>> I am using tools that expect host names instead of domain names (in
>> this case, dig);
>
> I think I must be misunderstanding something, or at least haven't
> imagined widely enough t
On Jan 4, 2021, at 7:44 PM, Viktor Dukhovni wrote:
>
> On Tue, Jan 05, 2021 at 02:39:27AM +, Paul Hoffman wrote:
>
>> Greetings again. Those of us who research DNSSEC adoption in the real
>> world are being a bit stymied by some of the sign-on-the-fly systems
Greetings again. Those of us who research DNSSEC adoption in the real world are
being a bit stymied by some of the sign-on-the-fly systems, such as this one,
apparently from UltraDNS. (Similar results are given for any nonexistent name
in house.gov, such as "www1".)
--Paul Hoff
breakage. Device manufacturers tend to use
a small number of codebases from a small number of OEMs for years at a time, so
alerting them of problems will make the DNS work better for many people.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
uot;update your
firmware", consider "update your firmware or upgrade your hardware from a
different brand". Brands that have a single UI across their line tend to be
more supportable.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
__
ven flag day, please be clearer about that
on the web page. Those who will be hurt by the edge case failures that this
flag day causes will the authoritative and resolver operators, not the vendors.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_
ne's logs,
if we can find people who are logging.
> That is the kind of thing that Geoff and George are good at, so if they want
> to do such an experiment and let us all know the results, I think that would
> be interesting.
That, too.
--Paul Hoffman
smime.p7s
Descriptio
or IPs are exhibiting the behavior.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
On Aug 31, 2020, at 12:40 AM, Thomas Mieslinger wrote:
>
> On 8/29/20 5:50 PM, Paul Hoffman wrote:
>> On Aug 28, 2020, at 3:24 PM, Puneet Sood via dns-operations
>> wrote:
>>> We would be interested in hearing other operator's experience here.
>>> Are
ive operators about what their configuration is so
that we can maybe guide others away from this path.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns
Shouldn't this part of the thread (proposed changes base on an Internet Draft)
be in the DNSOP WG in the IETF? Said another way, if you don't move it there
soon, when the topic appears there, you'll have to repeat yourselves.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptogr
Ad the problem seems fixed now, at least from the vantage points I use
(which hit Cloudflare at various places).
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
On Jan 23, 2020, at 12:54 PM, Marco Davids wrote:
>
> Op 23-01-20 om 21:26 schreef Paul Hoffman:
>
>> It looks like ISC had bad code (or bad configuration) for answers to
>> dig @f.root-servers.net net in ns +nsid
>>
>> At this moment, from any place I
It looks like ISC had bad code (or bad configuration) for answers to
dig @f.root-servers.net net in ns +nsid
At this moment, from any place I try, answers are coming back from
pao1a.f.root-servers.org or pao1b.f.root-servers.org, according to the NSID.
--Paul Hoffman
smime.p7s
Description
On Jan 17, 2020, at 10:10 AM, Alexander Dupuy via dns-operations
wrote:
>
>
> From: Alexander Dupuy
> Subject: EDNS Client Subnet (ECS) in queries sent to Google Public DNS
> Date: January 17, 2020 at 10:10:19 AM PST
> To:
>
>
> If any reader of this list is sending DNS requests with the ED
excellent example of a common situation where such a signature
might be caused to occur. Thanks!
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns
the scenario where "I" can get "you" to sign an
RRset? Aren't RRsets all signed by their owner, the creator of the RRset? If
I'm a signer and I'm willing to sign something that I didn't create, I already
have a lot of problems already.
ignature
> period, the collision will break once the RRset is resigned with
> a different inception/expiration interval).
A DNSKEY RR is only useful if there is a matching DS in the parent zone that
matches the DNSKEY. In your scenario, that would require a preimage attack.
--Paul Hoffman
sm
e effective. Further, when discovered, and the real zone owner sends out
another blast of "please refresh my zone", recipients might think "I already
did that" and ignore it.
Thus, the protocol proposed probably has to involve a requirement for DNSSEC
validation of announ
On Mar 10, 2015, at 8:46 AM, David C Lawrence wrote:
>
> Paul Hoffman writes:
>> On Mar 10, 2015, at 6:25 AM, Yunhong Gu wrote:
>>> So the problem is, why NOTIMP? REFUSED sounds like a better choice.
>>
>> +1. "REFUSED" exactly describes what is goin
On Mar 10, 2015, at 6:25 AM, Yunhong Gu wrote:
> So the problem is, why NOTIMP? REFUSED sounds like a better choice.
+1. "REFUSED" exactly describes what is going on.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists
are losing mail in a way similar to what
refusing to do ANY will cause, yet this isn't making the news. The new world
doesn't care about mail non-delivery so much...
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.d
o their implementation.
>
> The API design isn't the real issue here, it is interacting with the
> Name Service Switch in a way that is compatible with all existing NSS
> modules.
Yep, that's part of the implementation, and Verisign seems quite aware of it.
Note, too, that
e library you got from somewhere).
Difficult, but not impossible. The getdns API included non-DNS information from
the beginning, and Verisign is working on getting that part into their
implementation.
--Paul Hoffman
___
dns-operations mailing list
dns-operati
ork. after the tenth anniversary of
> SAC004 came and went, with more rather than fewer edges lacking SAV. 25/sec
> of signed nxdomain is enough to overload any DSL circuit. i'd be happy to
> work with you to find an upper limit.
OK, now it sounds like you don&
orly-thought-out experiment on the live operating DNS
with, as usual, insufficient data about the experiment being collected. If I'm
wrong, and your number of "25/sec" is based on analysis and data, it would be
great for you to share it here.
--Paul Hoffman
names and documentation are
inadequate. Please strongly consider having ISC-f talk to ISC-BIND about the
admin interface for RRL, including possible warnings for clearly bad
configurations.
--Paul Hoffman
signature.asc
Description: Message signed
that is the intention.
The only people who can say what the intention of the F-root servers is the
folks who run it.
> Is there an
> official policy on root-servers that allow AXFR yet?
No.
> Can one count on this
> working?
No, but you can add tooling to be sure that you are ge
Are there any Route 53 people on this list? If so, this should be fixed ASAP.
--Paul Hoffman
> On Jan 28, 2015, at 11:28 AM, Fred Morris wrote:
>
> I just noticed that when configuring firewall rules for an AWS instance,
> if "DNS" is chosen then the (only) protocol auto
ts to use them, yes
it certainly would.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
re going to trust them to give you the root
NS RRset you can trust them to give you a TLD referral", which seems about
right to me. That is, is there really a reason for starting the cache with a
query for ". IN NS" instead of just "whatever IN A"?
--Paul Hoffman
On Dec 18, 2014, at 5:26 PM, Michael Sinatra
wrote:
> Thread summary for dns-operations thread "knot-dns":
>
> Total Messages: 38
> Total Size: 298KB
> Thread Content Summary: "It's another trade-off."
Pertaining to thread title: 5%
___
dns-operati
7;m not seeing how zone walking validates the
contents of the glue records.
> i think walking the existing zone and verifying that there are no records
> between the nsecs and that every signature is valid and that the nsec chain
> ends at the apex, is simpler.
It is. Unless I'
; however, they are all more complex, and some involve using
the zone signing key for signing something other than the contents of an RRSIG.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailm
ight have the folks you want.
There are various groups outside of ICANN that might as well. Two that come to
mind are CENTR and APTLD.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman
On Oct 23, 2014, at 10:29 AM, Andrew Sullivan wrote:
>
> On Thu, Oct 23, 2014 at 07:25:46AM -0700, Paul Hoffman wrote:
>> Speaking as someone who supports all end systems to be their own validating
>> recursive resolver.
>
> "Validating" I get. Why recursive?
ere is only
> one rcode field. So I don't think that option is as easy as the paper
> makes it out to be.
Fully agree. This would be a huge protocol transition, and probably not even
worth considering.
--Paul Hoffman
___
dns-operations m
On Oct 20, 2014, at 10:03 AM, Joe Abley wrote:
> RSSAC are getting ready to publish a document relating to coordinated
> measurement of traffic seen by the root server system. I can't speak for
> others, but personally I would like to see a similar effort standardising the
> geographical and to
ing reports, and anycast
location and proliferation has not been covered in the reports covered so far.
Has anyone (maybe DNS-OARC?) kept snapshots of this type of data? Any clues
would be appreciated.
--Paul Hoffman
___
dns-operations mailing list
dns
On Sep 15, 2014, at 10:00 AM, Wessels, Duane wrote:
>
> On Sep 11, 2014, at 6:12 PM, Paul Hoffman wrote:
>
>> On Sep 11, 2014, at 4:27 PM, Paul Vixie wrote:
>>
>>> for the time being, and perhaps for a long time to come, the
>>> people who call the p
list to re-debate what ICANN should have
done for new gTLDs. There was plenty of earlier discussion in ICANN and at the
Verisign workshop. ICANN made a decision and implemented it. Arguing about that
history here is about as useful as arguing about the history o
ts absence a bug.
How do you measure that? This is a serious question, one that affects DNS
operators. If you have a way of determining how many enterprises are negatively
affected as a new gTLD rolls out, that would be very useful information.
--
fter that date. But
> only .otsuka has the records:
Also correct. So, before any of those TLDs start doing anything other than "I'm
in the root zone" and "I have A records for nic", they have to do the 90-day
controlled interruption.
--Paul Hoffman
the attacked site, while simply making up a private key.
Paul W's incorrect answer assumes a bug where the MITM needs to have a valid
certificate. That is the most common case, but not the one relevant here; the
Apple bug allowed a certificate for which the private key didn'
ds like you have a
believable business case to want something there.
> A similar record has been in use under .at for ages, and never caused any
> technical nor administrative issues.
ccTLDs cannot have administrative issues because politics.
--Paul Hoffman
___
t as soon as they could. Which other agreements with
ICANN are they willing to break? Or, if this really is a simple mistake, which
other simple mistakes are they willing to make until ICANN tells them not to?
--Paul Hoffman
___
dns-operations mailing
agreed with ICANN that they would *not* put in the root zone.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/m
Either this thread does not pertain to DNS operations, or it will pertain to
them in the most painful way possible, involving forced name changes and
touching all machines on a network. Regardless, our discussing ICANN's name
choice policies will change nothing.
--Paul Ho
On Nov 15, 2013, at 12:41 AM, Stephane Bortzmeyer wrote:
> On Thu, Nov 14, 2013 at 06:02:23PM +0100,
> Phil Regnauld wrote
> a message of 25 lines which said:
>
>> I'm waiting for the first news articles reporting corporate
>> networks who've used .[insert new tld] as their private d
that have private TLDs. Note
that these are not the first to cause name collisions: the IDNs earlier in this
raft could have done so due to search lists, and of course, any new TLD causes
some collisions.
--Paul Hoffman
___
dns-operations mailing list
for me. Is there a history of
this being unsafe? Of being more safe than NSs whose names are in other TLDs?
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs
what sort of car you should get. :)
>
> Is there something wrong with this?
It could have been, but the responses were a few on one pole, a few on the
other, and a lot of "it depends". Some of the "it depends" responses leaned in
one direction, but some leaned in the the ot
see if X converged in a community such as this.
It didn't. That's a useful data point for people creating other protocols who
have to listen to commenters who say where resolvers need to be.
--Paul Hoffman
___
dns-operations mailing list
dns-op
tinue to rely on its ISP?
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
n yours:
Don't use passwords for registrant-registrar interactions, use public key
crypto. Put a copy of the public key in a new RRtype in the signed zone. When
the current zone owner wants to change the key (similar to a password change),
they update that record.
--Paul Hoffman
__
ling with exit status that "this zone is ok to serve".
> With a bit of state held on disk about previous zones you could include some
> of those temporal checks and perhaps catch a few more problems.
...but not all of them.
--Paul Hoffman
_
ey are asserting that the data behind a name is unprotected by
DNSSSEC.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oa
DNSSEC is more widely deployed?
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
I don't see why it is even a consideration.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
not solve (b), and probably not (a), for the Internet.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
information", but
not useful to "alphabetize the IDN TLDs" or even "figure out where IDN TLDs
appear in a list of all TLDs".
None of this has anything to do with DNS operations. That's the whole point of
the IDNA encoding.
--Paul Hoffman
_
is data
in the root.
This is a perfect application of Atom feeds, FWIW.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.d
mer might have gone way down and X didn't
notice it.
It will always hurt because it will always last longer than intended.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/l
e US context which I live in.
You have shown no evidence that these "cases" exist, much less that they hinged
on BCP38.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
nce-able document describing the
> RRL. That is, something stable and reviewed - and that could be an RFC.
> But an RFC does not have to come through the IETF.
Nor did anyone say it had to.
Please consider putting your straw man back on the shelf, and maybe help people
who want to
On Feb 4, 2013, at 11:39 AM, Andrew Sullivan wrote:
> On Mon, Feb 04, 2013 at 10:54:36AM -0800, Paul Hoffman wrote:
>> We now have two implementation of response rate limiting (RRL). In order for
>> it to be widely adopted, an Internet-Draft followed by an RFC would be
&g
On Feb 4, 2013, at 11:07 AM, Paul Vixie wrote:
> Paul Hoffman wrote:
>> We now have two implementation of response rate limiting (RRL). In order for
>> it to be widely adopted, an Internet-Draft followed by an RFC would be
>> Really Helpful.
>
> agreed.
>
>
. This work should begin
sooner, not after another implementation has started but gone in a different
direction.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns
te. The security offered by a system
that acts like an HSM is based on the belief that the ability to review all the
software used in the system will overwhelm the problems of too much software in
the system.
These are two orthogonal types of theater.
--Paul Hoffman
signed,
has the same properties.
There is a real question about whether HSMs or systems that act like HSMs have
side-channel attacks that would leak the private key.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
are-based HSM in a tamper-evident box would have the
same property.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.ne
way.
FWIW, I'm not saying that SoftHSM is the right design for an HSM-like box, but
rather that if we design a system that can replace HSMs and can be built for
$200, it will be deployed much more often.
--Paul Hoffman
___
dns-operations mailin
On Oct 3, 2012, at 7:42 AM, Paul Wouters wrote:
> On Wed, 3 Oct 2012, Paul Hoffman wrote:
>
>> I fully agree with all of this, but it leaves the question: what about
>> tunneling DNS in TLS-over-HTTP? The earlier statement about why this would
>> not work (c
ng MITM certificates from bad actors in the root pile)
doesn't actually apply because the client will have a single TLS trust anchor,
possibly even one not even in the root pile.
--Paul Hoffman
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
1 - 100 of 111 matches
Mail list logo
