viktor> Do the CPU and packet size reductions justify the additional
viktor> protocol complexity?
As IPv6 slowly creeps up in usage amongst folks not well versed in PMTUD
and such (particularly more and more smaller middleware/firewall vendors
or crap consumer routers), I think keeping response
shuque> The UltraDNS implementation doesn't use the more precise white
shuque> lies epsilon function defined in the spec, but it is probably
shuque> good enough for all practical purposes.
shuque> And it's much closer to white lies than "black" lies, because it
shuque> preserves the correct
shuque> UltraDNS (Neustar Security Services) is known to use NSEC White
shuque> Lies. I have a test zone there,
shuque> which you can examine: "[[ultratest.huque.com]]".
My recollection is that the NSS implementation is really grey lies,
i.e. not quite RFC white lies but not fully black like
fneves> I would like to start a discussion or to hear implenters and
fneves> operators of Full-service resolvers on what would be the best
fneves> software architecture or best current configuration practice to
fneves> handle a traffic pattern when a very popular name enters a
fneves> scenario
pe> If NASA borks their DNSSEC, the large recursive resolvers eat huge
pe> customer support costs but NASA is mostly unscathed (and may not
pe> even notice immediately). So the incentive to do better
pe> operationally is light for NASA but the resolver operators have very
pe> little leverage to
pe> NTAs in production use aren't even vaguely new. They've been in wide
pe> use for 8-10 years that I'm aware of. They are part of why folks
pe> like google, cloudflare, comcast et al are willing to do DNSSEC
pe> validation in production.
paul> i know that. i just don't like it. without
pounsett> Negative Trust Anchors, most probably.
paul> i hope not. because if true, there's no backpressure on sloppy
paul> operations. are we really introducing a new animal to this
paul> ecosystem that has no predators trying to kill or eat it?
NTAs in production use aren't even vaguely new.
dukhovni> A client using 8.8.8.8 as its iterative resolver and
dukhovni> delegating all input validation to that upstream becomes
dukhovni> vulnerable not only to data forgery, but also to validation
dukhovni> bypass if an MiTM pretending to be 8.8.8.8 returns unvalidated
dukhovni> data.
In a
pe> DNS is a complicated, esoteric knowledge set. The reason apps,
pe> middleware and various other boxes mucking with DNS in transit tend
pe> to suck is exactly because the programmers on those boxes don't have
pe> this expertise and make all sorts of bad assumptions about what is
pe> safe/sane.
pe> Resolver coders are vastly more likely to have knowledge of what
pe> might break, what is unsafe, etc. And if they miss a check, the odds
pe> of said resolver coders finding this out quickly, and fixing it and
pe> getting it deployed, are much better than expecting apps or
pe> middleware box
dukhovni> I am far from convinced that it is the resolvers job to
dukhovni> enforce RDATA syntax restrictions beyond what is required for
dukhovni> a valid wire form.
dukhovni> If applications make unwarranted assumptions about the syntax
dukhovni> of DNS replies, that's surely an application
bsomers> My argument goes something like this. When a DNS request is
bsomers> sent, the client (whether a stub or a resolver) is the most
bsomers> qualified to know specifics about the "connection" and is also
bsomers> the target of fragmentation attacks.
I'd go the other end of the spectrum.
warren> We've often discussed if the tools are useful / doing what we
warren> want. My concern with this is that it requires yet another app
warren> installed for people to communicate;
I'm one of the first to bitch about this when I have to install yet
another app.
However, mattermost works
matthew-l> I wonder whether the first one (SERVFAIL for NS) is a clue.
matthew-l> bcpe.fr is delegated to the same servers which do not answer
matthew-l> NS queries. Thus, NS RRSET is only available from the parent
matthew-l> (.fr) and not the child. Maybe this upsets child-centric
matthew-l>
daniel> Thank you for this. Is there any chance at all I can get you to
daniel> do a traceroute to
daniel> 185.203.205.10 and 2a0c:d2c4::53:5:7335
daniel> And if you have access to a bgp speaking peer, show ip bgp
daniel> 185.203.204.0/22 and show bgp ipv6 unicast 2a0c:d2c4::/32 (or
daniel>
jreid> In principle, they could all change at once, In reality, they
jreid> don't.
dot> But they do. Vanuatu did yesterday, and I mentioned some other
dot> recent examples in this thread a couple of weeks ago:
dot>
https://lists.dns-oarc.net/pipermail/dns-operations/2019-November/019486.html
mallman> I wonder if we're ever allowed to just decide this sort of
mallman> thing is ridiculous old shit and for lots of reasons we can and
mallman> should just garbage collect it away.
ebersman> We aren't allowed as IETF/engineers. The world sort of is. ;)
tale> I see the :) but I'm thinking
ebersman> IPv4 reachable traditional DNS servers for some tiny group of
ebersman> antique folks will be needed for years, even if we get 99+% of
ebersman> the world to some new system.
mallman> I wonder if we're ever allowed to just decide this sort of
mallman> thing is ridiculous old shit and
mallman> Setting aside history and how things have been done and why
mallman> (which I am happy to stipulate is rational)... At this point,
mallman> are there tangible benefits for getting information about the
mallman> TLD nameservers to resolvers as needed via a network service?
The biggest
ebersman> Actually, it's a great argument for longer TTLs and caching
ebersman> doing what they're supposed to.
jim> It would be if the root only got queries from well behaved
jim> recursive resolvers. But we both know Paul that simply isn't true.
jim> Well over 90% of the query traffic at the
jim> What do you consider to be a lot of queries? The root server system
jim> collectively handles 500K-1M queries per second. That seems rather
jim> a lot to me. YMMV.
fw> But globally? For the entire planet?
fw> It's certainly beyond what I can run out of my basement using spare
fw> parts,
ebersman> No need to shout... And the same could be said of RFC 1918 but
ebersman> ISPs have used that for thousands of homes, crossing thousands
ebersman> of CPEs. Not the best choice and not your choice but it does
ebersman> work for some folks.
marka> Advertising RFC 1918 address as DNS
marka> When a *ISP* advertises a DNS server to its *customers* IT SHOULD
marka> WORK FOR ALL OF THE CUSTOMER'S MACHINES!
That doesn't mean it can't be ULA. And it would be hideous but you can
use LL if you flatten the broadcast domain. There are lots of reasons
why this isn't the best idea but
marka> DNS servers that are expected to be reached across sites need to
marka> be globally unique addresses which ULA and LL are not.
The IP address clients use to reach the resolver doesn't have to be the
same one that the resolver uses as source address when it queries. And
it's not uncommon to
24 matches
Mail list logo
