ation. But it probably could be arranged.
3) Squat under ".test". This breaks a couple of "should not" in RFC
6761, but is in line with the general philosophy that "Users are free to
use these test names as they would any other doma
;t
entirely agree (achieve consensus?) inside itself on the wisdom of
doing it. Getting it through an external application outside of IETF
decision logic and then bringing it into the IETF might be easier, if
not cheaper.
Maybe. Or maybe not.
-- Christian Huitema
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.
I would much rather let the GNS developers make these decisions rather
than have the IETF try to engineer user interactions on their behalf. If
they have concluded that they just need a name suffix, I think we should
take that at face value.
But then, the GNS interaction design should also be ba
propriate. That will cost something, but nowhere near $200K, let alone
$25M. That's as close a permission-less innovation that one could get.
-- Christian Huitema
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
the root, as in, "out of 100
queries to the root, on average 7.3 will be for .local".
.corp is also visible, but with 0.3% of root traffic it ranks 13th among
the top leaked domains. .onion is barely visible, with 0.01% of root
traffi
t of uncertainty. If "giraffe.alt" comes with some permanency, then
".alt" does solve a problem.
-- Christian Huitema
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
"spoofing
by recursive server" is a threat, then having the recursive set bits to
affirm that the response is verified is not much of a protection -- the
emphasis should move to verification by the client. I would love to see
this discussed.
-- Christian Huitema
On 6/7/2023 10:38 AM, Flo
lookup is for the current
address of the published server, which arguably may change more often than the
ESNI data. So with proper caching, all that can be optimized.
-- Christian Huitema
> On Jul 26, 2019, at 2:58 PM, Erik Nygren wrote:
>
> The need to bootstrap ESNI (encrypted
t; and ".localdomain", each accounting for about 0.5% of
traffic.
This pales in comparison to the computer generated unique names, which
account for 50% of the traffic seen at the root -- about equally spread
between generated lengths of 7 to 15 characters.
-- Christian Huitema
On 8/1
ge fraction of root traffic.
The value of "local-root" vary. Some domains use an IP address. Many use
common names like "LOCALDOMAIN" or "LAN", some use the name of a local
server, some use the name of an access router. Arguably, they could use
a reserved 2LD under ALT, although I am not holding my breath...
-- Christian Huitema
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
should refuse to load any .alt zones. It is
> supposed to be Special Use for non-DNS protocols. Why let it be abused
> as "real" DNS zones? Do we want to support "almost DNS like" protocols
> that would re-use authoritative DNS server code? That seems very
> dangerous.
Yes.
Most of the early tests of QUIC were using port 4433, not 443. Using
alternate ports for testing is very common.
-- Christian Huitema
On 1/3/2020 10:01 AM, Erik Kline wrote:
> I think removing port number flexibility might unduly constrain some
> data center use cases where service reacha
d thus tend to
diminish the traffic to the root.
And now, for a "Carthago delenda est" moment, let's point out that
almost 50% of the traffic to the root comes from the Chrome browser
making up randomly named TLD to probe whether the local ISP is hijacking
NXDomain replies. If we really want to reduce the leaks to the root,
there is that.
-- Christian Huitema
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
terly 3 to 5.
Smooth or slight becoming slight or moderate. Showers. Good.
Adding test vectors would help, especially broken vectors.
+1. That would be a pretty good way for the IETF to help clean the mess.
That, and maybe a DNS site that would serve the test vectors.
On 4/15/2021 5:39 PM, John R Levine wrote:
On Thu, 15 Apr 2021, Christian Huitema wrote:
Adding test vectors would help, especially broken vectors.
+1. That would be a pretty good way for the IETF to help clean the
mess. That, and maybe a DNS site that would serve the test vectors.
In
pessimistic as you like, but in Sweden, more than 80% of the ISP
> resolvers validate. The DNS can change, at a sometimes glacial speed,
> but it does change.
According to https://ithi.research.icann.org/graph-m5.html, the worldwide
fraction of public DNS that performs DNSSEC
f those, there is just
one scenario for which the claim has some legitimacy: if the company
pays for my laptop and own the laptop, yes of course it has a legitimate
claim to control how I am using it. Otherwise, I, the user, get to
decide. If I like the application's setting better than t
many cases in which the
contractual power of the network is limited -- thinks like fair access,
network neutrality, etc. Just claiming an empire does not automatically
make you the emperor.
-- Christian Huitema
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e been called to decide that
sort of things, in particular for various "shrink wrap" software
licenses. The results vary. Sometimes the courts let the fine print
stand, some times they treat it as an abuse of power and nullify it.
Which points exactly to Stephane's characterization:
tled to override the user choices and impose their own. Really?
As Stephane wrote, that may be legit in some circumstances, but much
more questionable in others, such as a hotel Wi-Fi attempting to decide
what sites I could or could not access. It really is a tussle.
-- C
des public accommodation.
Just like hotels cannot discriminate against some categories of
customers, I don't think that places providing public connectivity
should be able to discriminate against content accessed by their guests.
-- Christian Huitema
___
trolled by the user. You
are claiming that safety mandates giving the network operator full
control over name resolution. Both of these positions come from specific
visions about how the network should work. Neither is more a political
goal than the other.
-- Christian Huitema
___
d middle-boxes and filtered
content because they could. They did not exactly try to get a mandate,
or obtain consensus that this was proper. Technologies like DoH force
the discussion in the open. Why do you think you can filter content? Who
made you king?
-- Christian Huitema
__
On 3/12/2019 9:25 PM, Vittorio Bertola wrote:
>> Il 13 marzo 2019 alle 4.39 Christian Huitema ha
>> scritto:
>>
>> On 3/12/2019 7:56 PM, Vittorio Bertola wrote:
>>> The reaction I got from some policy people when I mentioned this kind of
>>> argumen
On 3/13/2019 9:56 AM, Livingood, Jason wrote:
> On 3/12/19, 11:40 PM, "Doh on behalf of Christian Huitema"
> wrote:
>
>> Why do you think you can filter content? Who made you king?
> [JL] End users may have opted into / subscribed to such a parental control
>
cking phishing sites" and "blocking content
that I disagree with". The various attempts to block the whole of
Wikipedia in order to block some specific pages shows where this can lead.
-- Christian Huitema
signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
you IP a.b.c.d which sadly is the external IP on the NAT
> exiting the corporate network has a problem. So great one of
> potentially 1000’s of devices is infected but not really much better
> information than that. In effect exactly what most security operations
> teams assume is true
ould be
forced to trust the DNS resolver provided by the local infrastructure. Another
position is that users have the right to apply their own policy and decide
which server they will trust, based on some configuration.
-- Christian Huitema
___
DNS
he short summary is that the proposed PTR would be a "super
cookie." Consider that some ISP periodically change the IPv4 addresses or
IPv6 subnets allocated to customers, in order to help protect the users'
privacy. Following the rec
29 matches
Mail list logo
