Re: [DNSOP] KSK-Sentinel -- "Walkin' on the SUN"?
Mark Andrews wrote: Underscore prefix names are entirely user convention the same way as IN-ADDR.ARPA and IP6.ARPA are user convention. There is NOTHING in resolvers or name servers that treat these names as special in any sort of way what so ever. ... i think the ability to log warnings or generate errors if A/ owners or MX/NS targets are not RFC952-style "hostnames" (that is, if they have underscores in them) in BIND8 and BIND9, is a case of treating such names as if they are special. "good? bad? i'm the one with the gun." --ash, in _army of darkness_ -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] KSK-Sentinel -- "Walkin' on the SUN"?
Underscore prefix names are entirely user convention the same way as IN-ADDR.ARPA and IP6.ARPA are user convention. There is NOTHING in resolvers or name servers that treat these names as special in any sort of way what so ever. gethostbyname and getnameinfo just implement the user convention. ksk-sentinel requires validating recursive servers to have different code paths for names that start with these labels. That makes them special. As for nothing breaks if you don’t implement, that is true of most/all names in the special use registry to exactly the same extent as not implementing ksk-sentinel doesn’t break anything. > On 16 May 2018, at 3:24 am, Ted Lemon wrote: > > Hm, well, the analogy I was making is that this is essentially a signal to an > application, which happens to be a caching name server. "Other name servers > treat them as ordinary names" is not a reason not to list a special-use name > in the registry. Ideally we want names like this to have as small an > implementation footprint as possible. The reason I am objecting to the idea > that this is a special-use name is that it doesn't seem fundamentally > different to _tcp, aside from the detail of what software happens to consume > it. Special-use names do generally require special treatment by the system, > even though we hope that the footprint will be as small as possible. Right > now entries in the table are either not global names (which doesn't apply > here) or are intended for special purposes (e.g., example.com, invalid), or > require a protocol other than DNS to resolve (local, onion). > > The case for handling this as a special-use name is that we'd want > implementors of naming software to find it in the registry so that they'd > know to do it, but I don't think that applies here—the downside to not doing > it is that you don't get the new feature, not that something breaks. That's > very similar to the downside of not knowing what _tcp means. > > On Tue, May 15, 2018 at 12:39 PM, Matthew Pounsett wrote: > > > On 15 May 2018 at 12:34, Tony Finch wrote: > Ted Lemon wrote: > > > It might be useful to compare this to labels like _tcp that appear in SRV > > records and elsewhere. > > The reason for listing a name in the RCF 6761 registry is because it needs > special handling of some kind in DNS software. That isn't the case for the > _underscore names, which (from the DNS point of view) are just ordinary > domain names that have conventional uses in applications. > > I'm going to suggest a modification to your first sentence. The reason for > listing a name int he RFC 6761 registry is because it needs special handling > of some kind in DNS software that would otherwise be unaware of the special > handling required by that name. In this case, the only name servers that > need to handle these names specially are the ones implementing the > technology.. all other name servers treat them as ordinary names. > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4
> On May 15, 2018, at 3:57 PM, John Levine wrote: > > I think it's a swell idea to offer people DNSSEC testing services but > it's hopeless to conflate it with key rotation. I completely agree with you on key rotation, once the zone has already been operating signed. But the document also covers enrollment: This document describes a simple protocol that allows a third party DNS operator to: establish the initial chain of trust (bootstrap --- DNSSEC) for a delegation; update DS records for a delegation; and, remove DS records from a secure delegation. The DNS operator may do these things in a trusted manner, without involving the Registrant for each operation. This same protocol can be used by Registrants to maintain their own domains if they wish. It is at the time of initial enrollment that I'd like to propose greater due diligence. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4
In article <8e5d5d6c-6893-473d-a2fe-dcb0b46e7...@dukhovni.org> you write: >Some of the more subtle, but still very important failure modes >are not obvious unless *tested*. It is would be a disservice to >the ecosystem to blindly turn on only partly working DNSSEC which >is actually broken in important ways. I think it's a swell idea to offer people DNSSEC testing services but it's hopeless to conflate it with key rotation. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4
> On May 15, 2018, at 2:29 PM, John Levine wrote: > > I think you will find that attempts to legislate against being stupid > do not generally turn out well. It makes sense to check for mistakes > that might screw up the upper level name server like an invalid > algorithm number, but if they want to shoot themselves in the foot, > there's not much we can do about that. > > There's no way to make a list of every possible stupid thing that > someone might do, so I wouldn't try. Some of the more subtle, but still very important failure modes are not obvious unless *tested*. It is would be a disservice to the ecosystem to blindly turn on only partly working DNSSEC which is actually broken in important ways. Section 3.4 says: The Registration Entity, upon receiving a signal or detecting through polling that the child desires to have its delegation updated, SHOULD run a series of tests to ensure that updating the parent zone will not create or exacerbate any problems with the child zone. The basic tests SHOULD include: [...] And while we can't enumerate all possible breakage, there are clear mistakes that are comparatively common now, and which would become much more prevalent if enrollment is made easier with no due care to ensure that we're not adding to the problems. * Incomplete NSEC chains that break denial of existence of the TLSA records of any explicit (or implicit zone apex) MX hosts. * SOA signatures that are invalid (typically modified after signing) * RRtype-based query filtering that drops TLSA/CAA/... queries. * ... and a few more ... The above are not made-up hypotheticals, they are actually observed in sufficient numbers to establish a pattern of likely failure modes that need to be tested. I have around ~200 samples that provide strong evidence of the most common failure modes. We can perhaps quibble over which failures might be ignored, but it would be irresponsible and counter-productive to ignore them all. -- -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4
In article <1d06889c-770f-4f92-bf06-a76338aeb...@dukhovni.org> you write: >For example, nazwa.pl has recently signed a bunch of domains with lame >wildcard NS records under the zone apex. This breaks denial of existence >for all child domains, including TLSA lookups, and therefore breaks email >delivery to the newly signed domains. I think you will find that attempts to legislate against being stupid do not generally turn out well. It makes sense to check for mistakes that might screw up the upper level name server like an invalid algorithm number, but if they want to shoot themselves in the foot, there's not much we can do about that. There's no way to make a list of every possible stupid thing that someone might do, so I wouldn't try. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] KSK-Sentinel -- "Walkin' on the SUN"?
Hm, well, the analogy I was making is that this is essentially a signal to an application, which happens to be a caching name server. "Other name servers treat them as ordinary names" is not a reason not to list a special-use name in the registry. Ideally we want names like this to have as small an implementation footprint as possible. The reason I am objecting to the idea that this is a special-use name is that it doesn't seem fundamentally different to _tcp, aside from the detail of what software happens to consume it. Special-use names do generally require special treatment by the system, even though we hope that the footprint will be as small as possible. Right now entries in the table are either not global names (which doesn't apply here) or are intended for special purposes (e.g., example.com, invalid), or require a protocol other than DNS to resolve (local, onion). The case for handling this as a special-use name is that we'd want implementors of naming software to find it in the registry so that they'd know to do it, but I don't think that applies here—the downside to not doing it is that you don't get the new feature, not that something breaks. That's very similar to the downside of not knowing what _tcp means. On Tue, May 15, 2018 at 12:39 PM, Matthew Pounsett wrote: > > > On 15 May 2018 at 12:34, Tony Finch wrote: > >> Ted Lemon wrote: >> >> > It might be useful to compare this to labels like _tcp that appear in >> SRV >> > records and elsewhere. >> >> The reason for listing a name in the RCF 6761 registry is because it needs >> special handling of some kind in DNS software. That isn't the case for the >> _underscore names, which (from the DNS point of view) are just ordinary >> domain names that have conventional uses in applications. >> >> I'm going to suggest a modification to your first sentence. The reason > for listing a name int he RFC 6761 registry is because it needs special > handling of some kind in DNS software that would otherwise be unaware of > the special handling required by that name. In this case, the only name > servers that need to handle these names specially are the ones implementing > the technology.. all other name servers treat them as ordinary names. > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4
> On Apr 28, 2018, at 1:28 AM, Viktor Dukhovni wrote: > > So at this point I think we understand each other, and the issue comes down > to whether it is appropriate for the registry to automatically turn on DS > records for the first time for a domain which is substantively operationally > deficient at the time its CDS records are encountered. > > I think that garbage-in/garbage-out is not only a disservice to the domain's > owner, but more importantly it poisons the ecosystem for everyone else. > > If turning on DNSSEC validation in your resolver stops email delivery to a > bunch of domains, or breaks all access to the domain's data, whom exactly is > the registry helping by enabling DNSSEC for a substantially broken domain. > > Think of this as anti-pollution environmental regulation. I see a new version -05, with (so far) the Section 3.4 acceptance text unchanged. I strongly feel broken DNSSEC adoption is much worse than no DNSSEC adoption, it not only has operational impact on the target domain, but also creates strong disincentives to enabling validation in resolvers. Therefore, if at all possible, broken implementations should not have their DS records published, and all reasonable effort should be made to detect known forms of breakage before inflicting such breakage on the world at large. For example, nazwa.pl has recently signed a bunch of domains with lame wildcard NS records under the zone apex. This breaks denial of existence for all child domains, including TLSA lookups, and therefore breaks email delivery to the newly signed domains. This is easily detected, and such detection should be part of acceptance criteria for having DS records published. Yes, some domains will introduce breakage after the fact, but we can and should avoid it at inception. $ grep nazwa broken | ... | xargs -n1 unbound-host -D -t tlsa validation failure <_25._tcp.andyandmag.pl. TLSA IN>: nodata proof failed from 85.128.129.10 validation failure <_25._tcp.fruty.pl. TLSA IN>: nodata proof failed from 85.128.128.10 validation failure <_25._tcp.funit.com.pl. TLSA IN>: nodata proof failed from 195.238.185.146 validation failure <_25._tcp.informica.org. TLSA IN>: nodata proof failed from 195.238.185.146 validation failure <_25._tcp.vitacard.pl. TLSA IN>: nodata proof failed from 85.128.129.10 validation failure <_25._tcp.sjedrzejewski.pl. TLSA IN>: nodata proof failed from 85.128.129.10 validation failure <_25._tcp.centrumuslugszklarskich.com. TLSA IN>: nodata proof failed from 85.128.129.10 validation failure <_25._tcp.ts3priv.pl. TLSA IN>: nodata proof failed from 195.238.185.146 -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Publication has been requested for draft-ietf-dnsop-session-signal-07
On 15.5.2018 11:16, Tim Wicinski wrote: Tim Wicinski has requested publication of draft-ietf-dnsop-session-signal-07 as Proposed Standard on behalf of the DNSOP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ For the record I still object to moving this to Proposed Standard. I believe this drafts adds way to many straws to Camel's back. -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] KSK-Sentinel -- "Walkin' on the SUN"?
On 15 May 2018 at 12:34, Tony Finch wrote: > Ted Lemon wrote: > > > It might be useful to compare this to labels like _tcp that appear in SRV > > records and elsewhere. > > The reason for listing a name in the RCF 6761 registry is because it needs > special handling of some kind in DNS software. That isn't the case for the > _underscore names, which (from the DNS point of view) are just ordinary > domain names that have conventional uses in applications. > > I'm going to suggest a modification to your first sentence. The reason for listing a name int he RFC 6761 registry is because it needs special handling of some kind in DNS software that would otherwise be unaware of the special handling required by that name. In this case, the only name servers that need to handle these names specially are the ones implementing the technology.. all other name servers treat them as ordinary names. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] KSK-Sentinel -- "Walkin' on the SUN"?
On 14.5.2018 20:10, Warren Kumari wrote: So, please,*clearly* state if you think that this: A: is a SUN B: is not a SUN B: is not a SUN. In my view special label is different kind of beast than SUN. -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] KSK-Sentinel -- "Walkin' on the SUN"?
Ted Lemon wrote: > It might be useful to compare this to labels like _tcp that appear in SRV > records and elsewhere. The reason for listing a name in the RCF 6761 registry is because it needs special handling of some kind in DNS software. That isn't the case for the _underscore names, which (from the DNS point of view) are just ordinary domain names that have conventional uses in applications. Tony. -- f.anthony.n.finchhttp://dotat.at/ promote human rights and open government ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] KSK-Sentinel -- "Walkin' on the SUN"?
On 14 May 2018 at 14:10, Warren Kumari wrote: > > So, please, *clearly* state if you think that this: > A: is a SUN > B: is not a SUN > > > I think this is not a SUN. 6761 has a lot of opportunity in its text to refer to leftmost labels and doesn't do that, not even in what could have been fairly obvious examples (e.g. localhost.*). Also, the SRV registry is not encapsulated in the SUDN registry, and that seems to me to be the same issue. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] KSK-Sentinel -- "Walkin' on the SUN"?
It might be useful to compare this to labels like _tcp that appear in SRV records and elsewhere. Those are not listed in the SUDN registry. I think that this also doesn't make sense to list there. It's an interesting question, of course, but I think we have a precedent that answers is. On Tue, May 15, 2018 at 5:53 AM, Tony Finch wrote: > Warren Kumari wrote: > > > > The authors are in disagreement - RFC6761 talks about "Special-Use Domain > > *Names*", not "Special-Use Domain *Labels*", but Stuart has said that it > > wasn't intended to be only for TLDs / pseudo-TLDs / things starting at > the > > top of the tree. > > Hmm. I think that if RFC 6761 were supposed to cover arbitrary labels then > it ought to have said something about localhost as a subdomain. > > > So, please, *clearly* state if you think that this: > > A: is a SUN > > B: is not a SUN > > KSK-sentinel feels like a new kind of thing, but I guess it has a lot in > common with let-localhost-be-localhost. So I think our answer should be > the same for both of them. > > My initial reaction was (B), but after I compared with localhost I think > (A) is probably the right answer. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Humber, Thames, Dover, East Wight: Northerly 5 or 6. Slight or moderate. > Fog > patches. Moderate, occasionally very poor. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] KSK-Sentinel -- "Walkin' on the SUN"?
Warren Kumari wrote: > > The authors are in disagreement - RFC6761 talks about "Special-Use Domain > *Names*", not "Special-Use Domain *Labels*", but Stuart has said that it > wasn't intended to be only for TLDs / pseudo-TLDs / things starting at the > top of the tree. Hmm. I think that if RFC 6761 were supposed to cover arbitrary labels then it ought to have said something about localhost as a subdomain. > So, please, *clearly* state if you think that this: > A: is a SUN > B: is not a SUN KSK-sentinel feels like a new kind of thing, but I guess it has a lot in common with let-localhost-be-localhost. So I think our answer should be the same for both of them. My initial reaction was (B), but after I compared with localhost I think (A) is probably the right answer. Tony. -- f.anthony.n.finchhttp://dotat.at/ Humber, Thames, Dover, East Wight: Northerly 5 or 6. Slight or moderate. Fog patches. Moderate, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Publication has been requested for draft-ietf-dnsop-session-signal-07
Tim Wicinski has requested publication of draft-ietf-dnsop-session-signal-07 as Proposed Standard on behalf of the DNSOP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
