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
>> 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?
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
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
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
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
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
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
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
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
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.
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
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 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
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
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
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
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
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
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> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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> 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
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
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
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
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.
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
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
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
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
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
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
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
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...
_
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
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!
___
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.
64 matches
Mail list logo
