gih> for what its worth I would like to chime in and support George's
gih> view. The technique is NOT a lie per se.
I'll "me too" this with George and Geoff.
Figuring out a more efficient way to do what is ultimately wanted
(crypographically provable denial of existence) that works better than
th
Perhaps if we inverted the logic? I realize this does broaden the
fundamental definition but what if, instead of saying "gave
non-authoritative response" we define lame as "failed to give an
authoritatve/AA response"?
>> I continue to think that if you don't get a response, you can't tell
>> wheth
>> Perhaps if we inverted the logic? I realize this does broaden the
>> fundamental definition but what if, instead of saying "gave
>> non-authoritative response" we define lame as "failed to give an
>> authoritatve/AA response"?
jtk> Isn't that what I originally suggested and Joe disagreed with?
mats> For the *delegation* to be lame it is not enough for one name
mats> server to be ``broken''. The entire set must be such that the path
mats> to the child zone content is not available.
mats> For individual name servers it could be meaningful that say that
mats> it is a *lame name server* in
olafur> My suggestion is to take a step back and say we have outgrown
olafur> AXFR and we need better mechanism to sync various servers.
olafur> Lets start work on a new "SYNC Name servers" protocol that can
olafur> meet modern requirements
paulw> +1
+1.
I think we're allowed to replace somethi
I was also one of those folks that put things in txt zone files for
years. My whole IP address management was comments in the in-addr.arpa
zones. While I went to dynamic zones to make DNSSEC easy and lost that,
I still see value in things that should be attachable to a zone but not
zone data and no
ebersman> Actually, I think this moves your goal nicely. If we could
ebersman> have things marked as "not zone data, sensitive" and dealt
ebersman> with only over a covert channel after various auth/acl checks
ebersman> are done, it would be easy enough to have metadata that won't
ebersman> leak.
rharolde> If you are looking at putting it outside the zone, it occurs
rharolde> to me that any of the IPAM solutions have a database where you
rharolde> can attach information to records, zones, IP addresses,
rharolde> etc. Even Active Directory can probably do that.
"Buy a commercial IPAM" isn't
dmahoney> I'd be fine with this data ONLY living on the master, but
dmahoney> having it survive things like named-compilezone or rndc
dmahoney> freeze/thaw, or the slew of DDNS updates that things like ACME
dmahoney> DNS-01 requires.
dmahoney> Effectively, this would be an internal-only DNS record
ebersman> If what you're arguing for is something that's actually mixed
ebersman> into the zone data, how do you handle non-compatible/legacy
ebersman> and avoid leakage?
wpk> non-compatible/legacy servers won't know the RRTypes that are
wpk> covert - and therefore won't be able to load them from
While there is definitely a lot of work needed, this seems to be getting
substantive interest in the draft, so I'd support the WG adopting this
draft.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
tjw> This starts a Working Group Last Call for
tjw> draft-ietf-dnsop-multi-provider-dnssec
[...]
tjw> Please review the draft and offer relevant comments.
I think this draft is in good shape. We've been using this as validation
of $DAYJOB procs around this area and have not found any holes in the
tmorizot> I would also like to understand why global and unique names
tmorizot> are unacceptable.
Why do folks insist on NAT and RFC 1918? or ULA v6?
There is a common feeling that it's another layer of security. I
personally am not a fan of it but I think this is probably the most
critica
bellis> AIUI, a large part of the supposed issue with SRV was the
bellis> inertia of the installed base of browsers that wouldn't know how
bellis> to access them.
drc> I thought the more fundamental problem was the additional latency
drc> caused by the second lookup since SRV specified domain name
tjw> This starts a Call for Adoption for:
tjw> draft-huque-dnsop-multi-provider-dnssec
I support adoption of this document.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
tjw> We discussed this and there appears to be support to adopt this,
tjw> with the caveat of adding more content to the section on
tjw> Operational Considerations.
[...]
tjw> Please review this draft to see if you think it is suitable for
tjw> adoption by DNSOP, and comments to the list, clearly
mellon> Think about DHCP providing an SMTP server address. Does that
mellon> make sense?
That doesn't. But DHCP already hands out DNS servers. You are already
trusting the DHCP server to give you default gateway and DNS server (or
you are choosing not to use DHCP).
Take the use case of coffee hou
pusateri> Another point I remember most clearly is that DHCP has fallen
pusateri> out of favor for communicating all but the most minimal
pusateri> network bootstrap configuration information. There was general
pusateri> agreement in the room that you only should use DHCP in IPv4
pusateri> for addr
ebersman> That may be the consensus at the IETF but it's not even close
ebersman> the consensus with ISPs, nor large enterprise. That seems to
ebersman> cover most of the eyeball/consumer... DHCP is still how much
ebersman> of the world gets connected and that hasn't changed in decades.
pusateri>
pusateri> Come to think of it, DNSSEC validation in the stub resolver or
pusateri> browser is really a place DoH could shine. Instead of all the
pusateri> round trips required for validating up (down) the chain, the
pusateri> webserver could package up all those validated records and
pusateri> push
ray> HTTP Redirects cause the URI in the address bar to be changed. A
ray> lot of the whole "CNAME at the Apex" issue arises because lots of
ray> marketing people don't want end users to have to type *or see* the
ray> www prefix.
ray> Those folks aren't going to stand for their nice clean
ray> "e
ray> Architecturally, the important part of my proposal is that
ray> resolution of the A and records is done *at the recursive
ray> layer* of the DNS, with no interference with how authoritative
ray> resolution works.
Have you confirmed with the large CDNs doing geo-ip, load-balancing, etc
th
mansaxel> IMNSHO _any_ work on "fixing CNAMES at apex" that gets
mansaxel> traction is a spanner in the works for what we seem to agree
mansaxel> is a better solution. A interim fix will be deployed and stall
mansaxel> every attempt at DTRT.
While I agree with this approach in principle, the reali
moura> We have a new draft and we'd like to ask the WG to adopt it:
moura>
[[https://datatracker..ietf.org/doc/draft-moura-dnsop-authoritative-recommendations/]]
msj> Do you have any authoritative server operators that have signed on
msj> to these recommendations other than the authors
I support these as a combined draft to be worked on by the DNSOP WG and
I'm willing to contribute editing/verbage.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
sfarrell> - section 2: "immediately restores" - well that depends on the
sfarrell> screw-up doesn't it? Or are you saying (where?) that an NTA
sfarrell> must only be put in place when the screw-up is specifically
sfarrell> and only about and because of DNSSEC and where ignoring DNSSEC
sfarrell> wi
Thanks for the comments and input.
bcampbell> Can an operator be reasonably expected to be able to confirm
bcampbell> that a domain is being operated by its rightful owner?
A fair amount of the time, yes. I run the DNS team for Comcast and we've
had pretty good luck getting to zone owners. Bette
nick> I like this and think it should be adopted as a WG doc. Am not
nick> going to volunteer for formal document review, but would be happy
nick> to run + provide feedback for this sort of code in a live
nick> environment.
I also support this being adopted as a WG document.
pk> At this time, after 25 IETF meetings, I have informed our AD that
pk> I'd like to step down from the position of a DNSOP co-chair and hand
pk> over the responsibility to somebody else to join Tim in chairing the
pk> group.
Thank you for all your time and contributions!
___
jabley> I would prefer the pragmatic option 5:
jabley> 5. Leave both registries as-is, publish Mark's document as-is,
jabley>and work on a separate registry clean-up draft later, since I
jabley>am guessing that work will not be uncontentious and the
jabley>guidance provided by the dra
ajs> giving useful advice, even if not perfect, on this topic will be
ajs> more helpful than producting perfect advice.
[...]
ajs> Please publish it.
+1
Many folks won't implement this until it's an RFC (.gov, etc.) but will
and give feedback once it's out. Perfect is the enemy of progress...
_
srose> I can't speak for all of .gov, but I think the draft is ready for
srose> publication. Once it has an RFC number it will get worked into
srose> products and ops manuals. Since a lot of .gov agencies
srose> outsource, or use appliances, I wouldn't expect much feedback. :)
Having worked rec
dougb> It's not just a philosophical objection, it's an operational
dougb> one. When DNSSEC fails for a domain there are 2 main
dougb> reasons. Operator error, and an actual MITM or similar attack. If
dougb> the operators of validating resolvers simply turn off validation
dougb> for domains that s
dougb> The other problem is that this feature is only really useful in
dougb> the DNSSEC ramp-up period. Sure, mistakes are more common now,
dougb> software is immature, etc. etc. But if DNSSEC is successful, the
dougb> software will get better (it already is a lot better than even a
dougb> few ye
ogud> We want humans in the loop, I would love to see a twitter feed
ogud> when ever Comcast does a Negative Trust Anchor.
phoffman> Like https://twitter.com/ComcastDNS, for example? Either
phoffman> things haven't been failing much lately, or they're not
phoffman> updating it as often as we had
pebersman> Have you actually read through the new draft? It specifically
pebersman> prohibits automatic installation of NTAs and says that you
pebersman> should have folks familiar with operating DNS servers making
pebersman> any decisions.
pwouters> That's my problem with the document. It descri
pwouters> So I'm confused. What is the goal of this document? How does
pwouters> it help us?
The other side of this document is that there 3 of the most popular
vendors of DNS server software have this out. We as the IETF should be
explaining the tradeoffs and risks of using an NTA.
I certainly
suzworldwide> The draft is available here:
http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/
suzworldwide> Please review to see if you think this document is
suzworldwide> suitable for adoption by DNSOP and comment to the list.
I support this draft as a working group i
srose> Should there be text describing auto-adding of NTA's based on
srose> important domains (for the ISP/resolver's definition of
srose> important)? So that domains that are used by low level services
srose> don't fail that also aren't normally visible to end users? One
srose> example is nist.
vixie> if there were an RFC (let's be charitable and assume it would
vixie> have to be an FYI due to lack of consensus) that gave reasons why
vixie> PTR's would be needed and reasons why the absence might be better
vixie> (so, internet access vs. internet service), then that RFC might
vixie> give
ebersman> I don't even know how many broken sites there are and I don't
ebersman> care to waste valuable staff time tilting at this
ebersman> windmill. ...
vixie> no worries. meanwhile i'm going to try to build an internet that
vixie> can grow for 200 more years.
Suddenly being "socially respons
ebersman> So your grand scheme is
vixie> decorum?
No objections here if you succeed. :)
ebersman> ... to limit who can get v6 PTRs and that will be the new
ebersman> standard of whether or now you're tall enough to send email
ebersman> with the big boys?
vixie> yes.
Well, for my $DAYJOB, that
marka> Or we could stop debating whether we should maintain it and
marka> assume that if we give people tools that will allow it to be
marka> automatically maintained they will eventually deploy them.
For providers with millions or tens of millions of end customers, any
system that just lets any
marka> Or we could stop debating whether we should maintain it and
marka> assume that if we give people tools that will allow it to be
marka> automatically maintained they will eventually deploy them.
[...]
marka> Document what a node should do to register itself in the reverse
marka> tree and to
marka> For in-addr.arpa you already have a PTR records. Allowing the
marka> end user to set its content does not increase the amount of data
marka> you are serving. It does increase the amount of churn in the
marka> zone.
This draft isn't talking about v4. And $GENERATE or equiv already works
i
phoffman> Do we know whether typical PTR checks look for existence or
phoffman> matching?
johnl> The ones I know all look for matching.
For MX/spam and for VPNs, seems to want matching. For more "fringe" uses
like NYT web, seems to just want a non-NXDOMAIN response.
I'd be nervous about wildc
To step back up a level again.
Most ISPs and most email/spam folks find the current v4 pointer usage to
be functional. I'm not saying that we all think it's not somewhat
broken, couldn't be better, etc. However, it solves the problems it's
supposed to solve in a functional way and doesn't generat
vixie> Indeed not. We currently have to maintain a large and complex
vixie> distributed registry of ipv4 ptr patterns which are meaningless
vixie> and must therefore be filtered out before making policy decisions
vixie> about the presence/absence and match/doesn't of a ptr record and
vixie> it's a
sthaug> If you assume that IPv6 mail servers have static PTRs, there is
sthaug> zero added value (and a bit of work) in creating/synthesizing
sthaug> IPv6 PTRs for residential customers. Much better to simply not
sthaug> do it in the first place.
I'm in agreement that "legitimate", well run mail
ebersman> It's a nice thought. But considering how little we've
ebersman> converged on SLAAC vs DHCPv6, random assignment vs eui-64 vs
ebersman> static for host ID, RFC 6106 vs DHCPv6 DNS, etc. (and I won't
ebersman> even start on how many IPv6 transition techs there are), any
ebersman> consensus
ebersman> My concern is random folks who currently accept any v4 PTR
ebersman> regardless of format (but caring if there is no PTR at all)
ebersman> will do something equally bad in v6. i.e. NYT web content and
ebersman> similar pointless cruft. Putting in an auto-gen'ed v6 PTR
ebersman> would sat
sthaug> To me this is really simple: If many/most ISPs continue *not*
sthaug> adding useless/artificial/synthesized PTRs, the content / server
sthaug> people will have no choice - if they want their content to get
sthaug> out and their services to be used by the large majority of IPv6
sthaug> user
I've come to the conclusion that this draft doesn't give me the data I
need to choose when/where/how I might do v6 PTRs for my broadband
customers. It is sufficient for servers, networking gear and business
customers; just not for broadband.
There are two things lacking that would be cleaner to t
ebersman> IPv6 is still in early adoption for broad general use and we
ebersman> don't know what plans folks have for requiring PTRs.
TLemon> I apologize for picking and choosing from your response, but I
TLemon> think this sums it up perfectly: if we do not yet know what
TLemon> plans they have,
kumari> I think that there is consensus that it is stupid. There is also
kumari> consensus that using a fork to get the stuck toast out of the
kumari> toaster is a bad idea -- however
york> I'm not sure that there's necessarily a whole lot of value in us
york> coming out with a document "Usin
TLemon> There may be some other reason why a bogus PTR record is better
TLemon> than no PTR record, but we are at present not aware of such a
TLemon> reason.
There is the NYT web site case and may be others.
In the past, ISPs have just pre-populated v4 PTRs because it wasn't hard
to do in config
ogud> The usage case that got brought up at the mike ``PTR records are
ogud> used by logging systems'' got me thinking ``when does a logging
ogud> system need this information'' and the answer is I think ``when a
ogud> human is looking at the log'' in all other cases if the system is
ogud> runni
ebersman> There is the NYT web site case and may be others.
TLemon> 'splain? I'm not finding anything with google.
Not sure if it's still the case but did confirm a couple of years ago
that NYT web access breaks if you don't have some kind of PTR. Doesn't
matter what's in it; you just need non
paul> Actually, distros try to use a dir.d/*.conf type structure these
paul> days for exactly this reason. It allows base options that are
paul> untouched to be upgraded even if there are custom user
paul> options. openssn is one of those that unfortunately does not
paul> support that.
Thanks for
tjw> This starts a call for adoption for draft-eastlake-dnsext-cookies.
[...]
tjw> Please review this draft to see if you think it is suitable for
tjw> adoption by DNSOP, and comments to the list, clearly stating your
tjw> view.
+1 to adopt and can review if needed.
It's another useful tool to h
warren> We are requesting a call for adoption of
warren> draft-wkumari-dnsop-root-loopback.
Support.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Apologies if you are on multiple lists and see multiple copies of this
email.
-
The next OARC Spring Workshop will take place in Amsterdam on May 9th
and 10th, the weekend before RIPE70. OARC is requesting proposals for
presentations, with a preference for DDoS attack reports and mi
ajs> I have read draft-ietf-dnsop-negative-trust-anchors-02. I have
ajs> some comments.
Thanks. These seem like reasonably comments and I'll fold them into the
doc.
Hope to have a new version out next week.
___
DNSOP mailing list
DNSOP@ietf.org
https
tale> At IETF this week it was decided to refocus the effort on the
tale> edns-client-subnet draft on only documenting the existing
tale> behaviour of deployed implementations.
f4t> That's disappointing and somewhat at odds with the theme of the
f4t> on-list discussions since the last draft was p
shane> I wrote a quick draft to specify that answers returned should be
shane> returned in a random order:
While it seems like a good idea to have the auth shuffle, my experience
from doing tech support for BIND and having this conversation way too
often is:
- there are way too many moving parts
edmonds> Overall I think it might make sense to have an informational
edmonds> document that describes the problem, the mechanisms that could
edmonds> be used in the DNS to address that problem (various kinds of
edmonds> reordering at different points in the stack, etc.), makes
edmonds> operational
66 matches
Mail list logo
