Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt
Wes Hardaker wrote: > > Because it's time... Better late than never :-) My draft from a couple of years ago describes some fun attacks you can perform on DNSSEC if you can generate a hash collision. So I think SHA-1 ought to be MUST NOT for signing, and there should be a concerted effort to get to the point where it can be deprecated for verification. https://datatracker.ietf.org/doc/html/draft-fanf-dnsop-sha-ll-not Appendix B. Timeline o 2005: Theoretical 2^63 attack on SHA-1 [Wang2005] [Cochran2007] o 2006: NIST starts to deprecate SHA-1 [NIST2006] o 2010: DNS root zone signed with RSASHA256 [ROOT-DNSSEC] o 2011: NIST formally deprecates SHA-1 for digital signatures, and disallows it after 2013 [NIST-SP800-131A] (section 3) o 2013: IETF recommends RSASHA1 for use in DNSSEC [RFC6944] o 2014: CA/Browser forum sunsets SHA-1 in X.509 WebPKI certificates after 2015 [CABforum2014] o 2015: Free-start collision demonstrated in SHA-1 [SHAppening] o 2017: Identical-prefix collision demonstrated in SHA-1 [SHAttered] o 2019: IETF partially deprecates SHA-1 for use in DNSSEC [RFC8624] o 2020: Chosen-prefix collision demonstrated in SHA-1 [SHA-mbles] -- Tony Finchhttps://dotat.at/ Channel Islands: West to southwest 2 to 4, occasionally 5, locally variable 1 to 3 at times south of guernsey this afternoon and evening, becoming generally southerly overnight. Smooth or slight. Occasional showers, locally heavy and thundery mist and a risk of patches, mainly in the north and west of the area at times. Good, occasionally moderate to poor, perhaps locally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: DNSSEC algorithm used on ietf.org
Petr Menšík wrote: > > I thought it is not a problem, because it contains multiple iterations. > Yet popular TLD has iterations==0. This is about how hash of name is > created from original Next Hashed Owner Name. No other algorithm for > this is defined. > > My conclusion is owner name hash is not security sensitive. But I never > saw that written in and RFC I read. I cannot say I read or know all > relevant drafts. Is it obvious to everyone but me? Maybe not obvious, but it is sort of implied by RFC 5155, because if you are not worried about zone enumeration then there's no point in heavy hashing. And since then there has been plenty of academic work showing how easy it is to enumerate a zone despite NSEC3. There is a fairly straightforward discussion of the issue in section 2.3 of this draft: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-nsec3-guidance -- Tony Finchhttps://dotat.at/ Fisher: West or southwest 2 to 4, occasionally 5 later. Smooth or slight. Mainly fair. Moderate or good, occasionally poor.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Fwd: DNSSEC algorithm used on ietf.org
Matthew Pounsett wrote: > On Wed, Mar 23, 2022 at 3:20 PM Petr Menšík wrote: > > > > Yes, it says so. It also says SHA-1 is not recommended for new > > signatures and ietf.org signature was made at 20220318000627. > > It's more accurate to say that it's not recommended for new > deployments. Operators are encouraged to migrate to more secure > algorithms, but given an existing deployment there's no MUST > associated with that migration, yet. That was a serious error in RFC 8624, that should have been called out when it was being prepared. Arguably, the same could be said for its predecessor RFC 6944. The lifetime of the signature is not relevant for the kind of collission attack demonstrated by the "SHA-1 is a shambles" paper, because the structure of an attack is: * attacker predicts the the framing in the signature chosen by the victim, things like the inception and expiration times * attacker generates colliding plaintexts, superficially benign (to be signed by the victim) and malicious; this takes some time * attacker submits a DNS update containing the superficially benign RRset, which is signed by the victim * attacker re-attaches the signature to the malicious RRset and uses it in a DNS record substitution attack. This is the same structure as previous successful attacks on X.509 certificates with MD5 signatures. As well as continuing to use a weak hash function, DNSSEC has not adopted any mitigations, such as hard-to-predict framing, that are used in the PKIX world. I have explained how DNSSEC is vulnerable to SHA-1 collisions in detail, but sadly I was not gentle enough about the way I said it, and various people on this list got upset and accused me of trying to break the DNS. Sheesh. Anyway, I-D version: https://datatracker.ietf.org/doc/html/draft-fanf-dnsop-sha-ll-not-00 Blog version: https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html https://www.dns.cam.ac.uk/news/2020-02-14-sha-mbles.html Also republished at: https://blog.apnic.net/2020/01/17/sha-1-chosen-prefix-collisions-and-dnssec/ -- Tony Finchhttps://dotat.at/ Lyme Regis to Lands End including the Isles of Scilly: East or northeast, becoming variable for a time, 2 to 4. In west, slight or moderate becoming slight later, in east smooth or slight. Fair. Good, occasionally moderate.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Bailiwick discussion for draft-ietf-dnsop-rfc8499bis
Paul Wouters wrote: > > As a seperate problem in the 2nd references email, I agree that the > term "in-bailiwick" probably changed meaning from "within this > delegation or below" to "the data related to this delegation". I view the term "in-bailiwick" as no longer suitable for use in careful writing because its meaning has become thorougly confused and muddled. Tony. -- f.anthony.n.finchhttps://dotat.at/ Dover, Wight: Northwest 3 or 4 veering north or northeast 4 to 6, becoming variable 3 or less later. Smooth or slight, occasionally moderate at first in north Dover. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis
Warren Kumari wrote:
>
> Viktor is suggesting that QNAME Minimization should be stopped when
> you run into an underscore ("_") label, instead of this being worded
> as a potential, optional mechanism.
This sounds sensible to me.
We have some _underscore delegations, because our VOIP phone setup
requires distinct internal and external views, and our main zones don't
support views. But, as in most of the other cases mentioned in this
thread, it isn't a privacy-relevant delegation point: there are only one
or two predictable SRV records in each delegated _underscore zone.
Tony.
--
f.anthony.n.finchhttps://dotat.at/
Southeast Fitzroy: Northwesterly 3 to 5, occasionally 6 later in
south. Moderate, occasionally rough at first in far north. Showers.
Good, occasionally moderate.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-13.txt
John Levine wrote: > > I'd also like it to say more clearly up front that .ALT is for names > that are totally outside the DNS protocols, not for names handled > locally using DNS protocols. It's for things like .onion, not like > .local. .local is a tricky example because it is used for mDNS (as discussed in the other replies) but it also has a history of being used as an ad-hoc RFC 1918-style domain. Microsoft recommended .local for use in Active Directory domain names for their Small Business Server, back in the days when you couldn't reasonably expect their target customers to register a real domain name. There are ugly hacks in mDNS implementations such as Avahi that try to work out what a network connection uses .local for. Tony. -- f.anthony.n.finchhttps://dotat.at/ Lundy, Fastnet, Irish Sea, Shannon: North or northwest, becoming northeast later, 4 to 6. Slight or moderate, becoming smooth or slight in Irish Sea. Showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt
Shivan Kaul Sahib wrote: > Hi all, Shumon and I have been working on an early draft that surveys > current DNS domain verification techniques. Depending on how it goes, we > hope to eventually explore if we can come up with some best practices. This looks like a useful document! One thing that's operationally awkward for me is how some providers do one-time verifications, and others re-validate periodically. I suppose there is another distinction between static re-validation done by (e.g.) Google, and dynamic renewal as required by ACME. Best practice for providers ought to be to document re-validation requirements very prominently and clearly. (In my experience the common ones are not too bad but occasionally we have to guess, so maybe a service stops working for mysterious reasons 30 or 90 days later.) It's kind of ugly the way static verification records clutter up the place, but on the other hand it is a useful protection against subdomain takeover attacks. So I hope that this document will have a good survey of the security considerations. Here's an overview of subdomain takeovers https://www.csoonline.com/article/3601007/how-to-avoid-subdomain-takeover-in-azure-environments.html Tony. -- f.anthony.n.finchhttps://dotat.at/ Southeast Fitzroy: Northerly or northeasterly 5 to 7, occasionally gale 8 at first. Moderate or rough. Fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance
Wes Hardaker wrote: > > So, what guidance do we want to insert? The text you wrote is exactly the kind of thing I was thinking of: > Operators of secondary services should advertise the parameter caps > their servers will support. Primaries need to ensure that secondaries > support the NSEC3 parameters they expect to use in their zones. > Primaries, after changing parameters, should query their secondaries > with appropriate known non-existent queries to verify the secondary > servers are responding as expected. Tony. -- f.anthony.n.finchhttps://dotat.at/ South Fitzroy: Northerly 4 to 6 in southeast, otherwise variable 2 to 4. Rough, becoming moderate or rough. Fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance
Wes Hardaker wrote: > Vladimír Čunát writes: > > > I'd also expect something on limits accepted by secondaries. And some > > details are probably up to further discussion (e.g. particular numbers > > and SERVFAIL), but I don't think such details would block adoption. > > That's certainly an interesting thing to think about, but it starts to > get in between the relationship of primaries and secondaries. Is that > something that should be "standardized"? The draft is operational advice, so I think the relevant advice here is that if you are signing your zone with slw NSEC3 parameters, make sure your secondaries are willing to serve such a zone first. Tony. -- f.anthony.n.finchhttps://dotat.at/ Fair Isle: Cyclonic becoming northeast, 4 to 6. Moderate or rough. Rain, fog patches. Moderate or good, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
Peter van Dijk wrote: > > Also in section 3.2, I do not think responding with the option should > be limited to NOERROR. Specifically, I'd very much also want it to work > for NXDOMAIN, Isn't the SOA record usually present in a negative response? > and I can imagine some cases of it being useful even in SERVFAIL cases > (at least in database-driven name servers like PowerDNS, where > individual records inside a zone can be broken). Perhaps also in cases where the server has a copy of zone serial number NNN but it has expired. Tony. -- f.anthony.n.finchhttps://dotat.at/ Viking, North Utsire: Cyclonic 6 to gale 8, becoming southerly 3 to 5. Moderate or rough, becoming moderate in North Utsire. Rain, fog patches. Moderate or good, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance
Benno Overeinder wrote: > > https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/. Yes, this is a helpful document that should be adopted by dnsop. I'm happy to review etc. Tony. -- f.anthony.n.finchhttps://dotat.at/ Biscay: Southwest 3 to 5 increasing 5 to 7. Rough, occasionally moderate in east, becoming very rough in west. Thundery showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements
John Kristoff wrote: > > However, I think we'd be reluctant to say much about minimal-answers > here in a context that suggests it is some sort of DDoS mitigation > mechanism and that you need it because... "TCP". Maybe there is some > adjustments to the text somewhere that can help highlight that certain > RRsets or settings may lead to more TCP traffic? There's this paragraph: Often, reducing the EDNS0 UDP packet size leads to a successful response. That is, the necessary data fits within the smaller message size. However, when the data does not fit, the server sets the truncated flag in its response, indicating the client should retry over TCP to receive the whole response. This is undesirable from the client's point of view because it adds more latency and potentially undesirable from the server's point of view due to the increased resource requirements of TCP. which is followed by discussion of various ways of reducing response sizes to avoid fragmentation and truncation. I thought that minimal-responses and minimal-any could also be mentioned as useful ways to avoid large responses. The anti-DDoS aspect of minimal-any isn't the main point in this context. > IETF RFC 2136 (UPDATE) is already referenced in our draft, section > 2.2. Is this insufficient? Oh yes, that's the kind of text I was expecting :-) I guess I had forgotten about it by the time I got to the appendix and thought it must have been missing because RFC 2136 isn't listed in the appendix. Tony. -- f.anthony.n.finchhttps://dotat.at/ Lundy: Northeast 4 to 6 becoming variable 4 or less. Smooth or slight, but moderate until later in west. Rain then showers. Good, occasionally moderate at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements
Wessels, Duane wrote: > Thanks for looking through my suggestions! All the changes look good. A few follow-up points: > Oops, correcting myself here. It needs to be RFC 2541 because that is the > one that mentions TCP. Aha, that makes sense > > 2.4: > > > > Last 2 paragraph s re. avoiding fragmentation, it might be worth > > suggesting minimal-any [RFC 8482]. > > I did add 8482 to the Appendix as you also suggested below. I'm a > little reluctant to add a reference in section 2.4 since I think the > primary motivation for 8482 was about DDoS amplification, rather than > fragmentation. But I could still be convinced otherwise. I needed minimal-any when my auth servers were being hammered by lots of recursive servers making ANY requests; the responses were being truncated because my servers have for a long time been configured to avoid fragmentation, and the retries over TCP caused an overload. I tend to think of all settings that reduce response size as tools for avoiding fragmentation. Which makes me realise that BIND's minimal-responses setting is probably also worth a mention. (I dunno if other servers have a similar knob?) > > A: > > > > Should RFC 2136 UPDATE be mentioned? (sections 2.1, 6.2, 7.8, 7.9) TBH I'm > > not sure how much UDP is used, but I certainly rely on 60+ KB updates. > > I probably don't have enough direct experience with UPDATE to say. If > it is largely over TCP then I think it should be included. I listed the main section numbers that mention TCP. One point in RFC 2136 that's notable from an operational point of view is that an UPDATE client has to use TCP if it wants to be sure to get a response. Unlike QUERY, UPDATE is not idempotent so UPDATE-over-UDP can't be retried when there is packet loss. (But `nsupdate` still uses UDP for small changes; I run it over localhost which is reliable enough.) Tony. -- f.anthony.n.finchhttps://dotat.at/ East Forties: Northwesterly 3 to 5. Moderate. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements
Suzanne Woolf wrote: > > This message starts the Working Group Last Call for > draft-ietf-dnsop-tcp-requirements I have read the draft and I am keen to see it published. Just the other day I was having a discussion about whether TCP support is really needed, and I wanted something stronger than RFC 7766 to point to. The draft is readable and comprehensive. I like it. Some minor and pedantic nits: 2.2: DNSSEC originally specified in [RFC2541] I thought this should be RFC 2535 rather than the operational guidelines? 2.3: This unsigned 16-bit field specifies, in bytes, the maximum (possibly fragmented) DNS message size a node is capable of receiving. I suggest adding "over UDP" to the end of the sentence (since the EDNS buffer size doesn't restrict messages over other transports). 2.4: Last 2 paragraph s re. avoiding fragmentation, it might be worth suggesting minimal-any [RFC 8482]. 4.3: the Linux kernel provides a number of "sysctl" parameters related to TIME_WAIT, such as net.ipv4.tcp_fin_timeout, net.ipv4.tcp_tw_recycle, and net.ipv4.tcp_tw_reuse. I believe that net.ipv4.tcp_tw_recycle is problematic and has been removed https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux#netipv4tcp_tw_recycle 4.4: Although DNS-over-TLS utilizes TCP port 853 instead of port 53, this document applies equally well to DNS- over-TLS. Um, how much of this document applies to DoT? Just the tuning advice, or the requirement that TLS MUST be supported like TCP MUST be? 5: re "DDoS mitigation techniques" would it be worth citing DNS RRL here as well as in section 9? 10: Since DNS over both UDP and TCP use the same underlying message format, the use of one transport instead of the other does change the privacy characteristics of the message content Missing "not"? A: Should RFC 2136 UPDATE be mentioned? (sections 2.1, 6.2, 7.8, 7.9) TBH I'm not sure how much UDP is used, but I certainly rely on 60+ KB updates. Also RFC 8482 section 4.4 talks about possible different behaviour for ANY queries over UDP compared to TCP. A.8: [RFC3226] strongly argued in favor of UDP messages over TCP largely I had to read this twice! How about "instead of" instead of "over"? A.14: I think there should be a note that RFC 5966 has been obsoleted by RFC 7766, with a cross-reference to A.21. (that's all I spotted) Tony. -- f.anthony.n.finchhttps://dotat.at/ Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North Channel: Southeasterly 3 to 5 at first in west, otherwise southwesterly 2 to 4, becoming variable 3 or less. Smooth or slight, occasionally moderate near Mull of Kintyre. Occasional rain. Good, occasionally moderate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A draft about the Name:Wreck problem draft-dashevskyi-dnsrr-antipatterns
Paul Vixie wrote: > > i shipped the crap in question as late as 1998 I absolutely honestly wasn't thinking of your crap at all :-) But your broader point about modern standards of excellence is well made. Tony. -- f.anthony.n.finchhttps://dotat.at/ Forties: Southeasterly 3 to 5, but variable 4 or less at times in east. Smooth or slight becoming slight or moderate. Fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A draft about the Name:Wreck problem draft-dashevskyi-dnsrr-antipatterns
John Levine wrote: > > On the other hand, all of the sloppy coding people use to handle > compressed names is embarassing. I don't think it's entirely fair to blame the coders who make these mistakes, because a very large number of excellent programmers have made a mess of DNS name decompression. When I find out about new DNS code the first thing I do is look at the name parser to see if it successfully avoids these traps and pitfalls, because it's a good indication that the programmer has learned from their own or others' mistakes, or has much greater than average ability to write attack-resistant parsers. It seems worthwhile to try to help future coders not to mess it up. Tony. -- f.anthony.n.finchhttps://dotat.at/ Gibraltar Point to North Foreland: Northerly or northeasterly 3 to 5. Smooth or slight becoming slight or moderate. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] private-use in-meeting chat comments
Eric Orth wrote: > On Tue, Nov 17, 2020 at 4:46 PM Tony Finch wrote: > > > > There's also a privacy leak: if you assign a unique subdomain then when a > > device roams and leaks queries for the private domain, the device can be > > tracked and correlated with other devices that use the same private > > domain. > > > > What if, in whatever hypothetical solution is using this, it is reasonable > for devices to always regenerate the names they are using on changing > networks? At least in such hypothetical cases, it seems the privacy danger > would be significantly mitigated, right? (Maybe we're getting too far into > unknown hypotheticals without finding actual usecases or implementors that > want this.) Ah, oops, I need to clarify: the private domain might be a per-CPE domain or an enterprise internal domain; the device is someone's phone or laptop which roams between multiple networks. The private domain is handed to the roaming device, and the device doesn't know (isn't told, and can't be told with current protocols) that the domain name is supposed to be private to the network. So the device is likely to keep asking about names of services in the private domain regardless of the network it is connected to, and thereby leak private information. Tony. -- f.anthony.n.finchhttp://dotat.at/ Southeast Iceland: Southeasterly 6 to gale 8, decreasing 4 or 5, then becoming cyclonic 7 to severe gale 9, occasionally storm 10 later in south. Rough or very rough, becoming high or very high later in south. Rain, squally showers later. Moderate or good, becoming moderate or poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] private-use in-meeting chat comments
Brian Dickson wrote: > > However, there's also another clever trick (for some value of $clever), > which isn't iron-clad but could help: > > guidspace.arpa DNAME empty.as112.arpa That's worse than leaving it unregistered :-) AS112 is OK for RFC 1918 reverse DNS because in that case the QNAMEs don't contain much information, but that isn't true for the forward DNS. Most of the privacy leak is to the hotspot network's resolvers (and their passive DNS partners); if the domain is registered then the resolver will send QNAMEs to its nameservers; if the domain points at AS112 then almost anyone might receive the QNAME leakage; if the domain is unregistered and the resolver does qmin then there's less leakage. This is really a general issue with split horizon DNS: whoever is assigning or giving advice about local/internal DNS needs to make it clear that the names aren't private and will leak. Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking: Variable 3 or 4, becoming cyclonic 5 to 7, occasionally gale 8 later. Rough, becoming very rough later. Rain at times. Moderate or good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] private-use in-meeting chat comments
Brian Dickson wrote: > One potential approach is to say (in the RFC) that one of the two-letter > reserved codes should avoid name collision by putting a collision-resistant > second-level label, below .zz and above the private use usage (and use that > particular two-letter code in that manner exclusively). This kind of thing, or guidspace.arpa, is not that different in terms of usability / ugliness from assigning a unique subdomain under a domain that has been registered in the normal way. There's also a privacy leak: if you assign a unique subdomain then when a device roams and leaks queries for the private domain, the device can be tracked and correlated with other devices that use the same private domain. I have a terrible mental conflict trying to weigh this privacy issue against the horrible consequences of encouraging people to squat on unassigned domains and use colliding hostnames. The privacy leak probably needs to be fixed regardless, and if it is fixed then there would be a bit less pressure in favour of unwise squatting. Tony. -- f.anthony.n.finchhttp://dotat.at/ Biscay: Southerly 3 to 5, veering westerly 5 or 6 later in northwest. Moderate, occasionally rough in northwest. Rain later. Good, occasionally moderate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hoffman-dnssec-iana-cons
Seems like a good idea to make this more consistent. A correction for the first paragraph: change DNSSEC is primarily described in [RFC4033], [RFC4034], and [RFC4035]. DNSSEC commonly uses two resource records beyond those defined in RFC 4034: DS [RFC3658] and NSEC3 [RFC5155]. to DNSSEC is primarily described in [RFC4033], [RFC4034], and [RFC4035]. DNSSEC commonly uses two resource records beyond those defined in RFC 4034: NSEC3 and NSEC3PARAM [RFC5155]. DS is specified in RFC 4034. I suppose it's OK to omit CDS and CDNSKEY sinec they don't have any separate IANA considerations :-) Is it possible to ask IANA to combine the registries a bit? I would prefer it if there were one page of DNS parameter assignments, or maybe two with a separate page for DNSSEC. At the moment there are: https://www.ietf.org/assignments/dns-parameters https://www.ietf.org/assignments/dns-sec-alg-numbers https://www.ietf.org/assignments/dnskey-flags https://www.ietf.org/assignments/dnssec-nsec3-parameters https://www.ietf.org/assignments/sig-alg-numbers And https://www.ietf.org/assignments/tsig-algorithm-names which is misfiled - it is not listed under the DNS heading at https://www.ietf.org/assignments/ Tony. -- f.anthony.n.finchhttp://dotat.at/ defend the right to speak, write, worship, associate, and vote freely ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Tell me about tree walks
Paul Vixie wrote: > > i'd like to be able to filter inbound traffic based on who paid the > money for a domain, who got that money, or whether either of them > wishes to remain anonymous. The crucial difference is that CAA/DMARC are consensual: the publisher and the checker both want to use the protocol to stop baddies doing bad things. But your situation is more adversarial: you (the checker) want to find out if the publisher is good or bad. There's not much chance of success trying to use a protocol designed for friendlies in situations of distrust, let alone active combat! Tony. -- f.anthony.n.finchhttp://dotat.at/ Southeast Iceland: Variable 4, becoming southeasterly 5 or 6, increasing 7 to severe gale 9 later. Rough, occasionally very rough later. Showers, rain later. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Tell me about tree walks
John R Levine wrote: > > > One possible way for DMARC to mitigate it would be to walk *down* instead > > of up, and (in the application, not relying on the recursive server) stop > > on NXDOMAIN because RFC 8020 tells you this is sensible, otherwise take > > the last result you find. > > I wouldn't want to skip the cache. In most settings there's a whole lot of > mail from the same place and most of the answers are likely to be cached. > Perhaps just note that if you're worried about this, use a cache the does RFC > 8020. Ah oops, I was too terse: I meant, use the recursive server as usual, but don't assume it implements RFC 8020: instead (re-)do the NXDOMAIN logic in the application. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: In southeast, easterly 4 to 6. In northwest, southwesterly 5 to 7, becoming cyclonic 4 or 5 later. In southeast, moderate. in northwest, moderate becoming rough. In southeast, fair. In northwest, showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Tell me about tree walks
John Levine wrote: > > It occurs to me that for DMARC's purposes, walking up the tree would > work better than the current hack. I know it would sometimes find a > different answer from what it gets now, which is OK. When this came up > before, the advice was that DNS tree walks are very bad, so don't do > them. Is that still true? Well, the other Very Prominent example is CAA records, which also involve walking up the tree to discover policy. It would be nice if things like CAA and DMARC could agree with each other about how they discover domain-wide policies. CAA records are perhaps less of a target for query amplification abuse than DMARC records :-) One possible way for DMARC to mitigate it would be to walk *down* instead of up, and (in the application, not relying on the recursive server) stop on NXDOMAIN because RFC 8020 tells you this is sensible, otherwise take the last result you find. Tony. -- f.anthony.n.finchhttp://dotat.at/ Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North Channel: Southerly 6 to gale 8, occasionally severe gale 9 at first in North Channel, veering westerly 4 or 5 for a time. Moderate or rough, becoming slight or moderate for a time. Rain at first, then fair, occasional rain later. Moderate or good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: RFC8499-bis
fujiw...@jprs.co.jp wrote: > > We need four types of glue names. > Please propose new names. I thought this was supposed to be documenting existing terminology, not inventing new terminology. There are two kinds of glue: * glue required by the DNS, for in-bailiwick nameservers * sibling glue, sometimes required by registries "in-bailiwick" is a property of a nameserver, not glue Tony. -- f.anthony.n.finchhttp://dotat.at/ Shannon, Rockall: Variable 3 or 4 at first in Rockall, otherwise cyclonic becoming southwesterly later, 6 to gale 8, perhaps severe gale 9 later. Rough or very rough. Rain at times. Moderate or poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: RFC8499-bis
I recently noticed that the bailiwick-related definitions are wrong and muddled. I have always understood in-bailiwick to mean that a nameserver name is a subdomain of its zone apex. That is, exactly the cases where glue is required by the DNS protocol. The term comes from the discussion of gluelessness at http://cr.yp.to/djbdns/notes.html - "RFC 1034 specifically requires glue for referrals to in-bailiwick DNS servers." RFC 8499 seems to use "in-domain" for this situation, which is not a term I have seen anywhere else. The question of sibling glue is different from whether nameservers are in-bailiwick. It comes up in questions about registry policies rather than DNS protocol needs: whether or not a registry requires all nameservers that are subdomains of the registry domain(s) to have addresses, even in cases where the DNS does not need glue. The description of siblings in RFC 8499 is muddled, because it is unclear when it is referring to a nameserver name or a zone name, and it's unclear when it is talking about a child zone or their shared parent zone. And the nameservers themselves aren't siblings; they are nephieces or niblings or something like that. I suggest: * Sibling zones: two zones whose delegations are in the same parent zone. * Sibling glue: addresses of nameservers that are in a sibling zone. Sibling glue is usually the glue that the DNS would require for that sibling zone, but in some cases the requirement lies elsewhere, for example one.example.NS nsa.two.example one.example.NS nsb.two.example two.example.NS ns0.two.example two.example.NS ns1.two.example The DNS protocol does not require sibling glue for the one.example nameservers, though glue addresses might be required by .example registry policy. Tony. -- f.anthony.n.finchhttp://dotat.at/ the fundamental values of liberty, equality, and community ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
Dave Lawrence wrote: > > Could you please clarify explicitly what should happen in the case of > encountering CNAMEs? Or DNAMEs? I guess when I originally sketched a qname minimization algorithm https://mailarchive.ietf.org/arch/msg/dns-privacy/gAgGx9Zz6W0OfyRdJ0Rx7xxmHDg/ I intended that it would slot into the RFC 1034 resolver algorithm https://tools.ietf.org/html/rfc1034#section-4.3.2 which treats QNAME as a variable name rather than a protocol field, so the QNAME changes when the resolver chases a CNAME. That was probably a bad idea: on balance I think it's better to make a clear distinction between protocol fields and variables in algorithms. Elsewhere RFC 1034 uses SNAME for the variable containing the name we are searching for https://tools.ietf.org/html/rfc1034#section-5.3.3 which would be better if it hadn't used QNAME for the same thing elsewhere :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ Fitzroy: Easterly 6 to gale 8, becoming cyclonic 5 to 7. Rough or very rough, becoming moderate or rough later. Thundery showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Going forward on draft-ietf-dnsop-private-use
Paul Wouters wrote: > > The IETF / DNSOP should not recommend setting up private space TLDs by > instructing people how to do this. +1 Tony. -- f.anthony.n.finchhttp://dotat.at/ Fisher: West or northwest 4 to 6, becoming variable 2 to 4 later. Moderate or rough. Fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
Ralph Dolmans wrote: > > Thanks for your feedback, appreciated! Thanks for the response! I thought of another thing: Some of the points in section 5 (on limiting the number of queries and the performance downsides) should be discussed in section 7 (security considerations). In particular QNAME minimization can amplify query volume so it can be abused to make random subdomain attacks worse, though that can be mitigated by RFC 8020 NXDOMAIN. Tony. -- f.anthony.n.finchhttp://dotat.at/ the quest for freedom and justice can never end ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
Stephane Bortzmeyer wrote:
> Tony Finch wrote:
>
> > Section 3, algorithm step 5: what is a "hidden QTYPE"?
>
> The original QTYPE, which may be "hidden" by a substitution to another
> QTYPE (see section 2 "a QTYPE selected by the resolver to hide the
> original QTYPE"). This was not in RFC 7816. Would you prefer we settle
> on "original QTYPE"?
I don't have a preference for any particular term, just that terminology
should be defined and used in a consistent way throughout the spec, so
that if you grep the draft for "hidden" (or whatever) you can find out
what what it means, and you can easily find every place where it is
relevant. ("elegant variation" is a bad thing in technical writing.)
> > Step 6, what is the "minimised QTYPE"?
>
> The opposite of "hidden QTYPE", it is the QTYPE choosen by the
> resolver (NS was recommended in RFC 7816, but it is A in 7816-bis).
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Great Orme Head to the Mull of Galloway: West 4, backing southwest 5 to 7,
veering west 4 to 6 later. Slight or moderate. Rain for a time, showers later.
Good, occasionally moderate.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
A few questions and suggestions: Section 3, algorithm step 5: what is a "hidden QTYPE"? Also step 5, a NOERROR answer can be positive or negative, so I think it should be made clear that this is about a non-NXDOMAIN negative cache entry. (RFC 2308 calls these "NODATA".) Step 6, what is the "minimised QTYPE"? The term is defined by implication in section 2, but a reader can't find the definition by searching for the term. Step 6b, again NOERROR can be positive or negative. I think either this needs to be more specific, or it should explicitly say it covers both cases. Step 6c, CHILD might not be the full original QNAME at this point, so it's only correct to stop on NXDOMAIN here if the resolver is doing RFC 8020 strict NXDOMAIN. Editorial suggestion: the wall of text in section 2 could do with some subheadings or bullet points. It would be helpful to make a more clear separation between rationale/discussion and normative text. I'm not a fan of the term "aggressive" since it sounds unpleasantly fighty. And I'm not sure how it helps a reader to understand this draft: AIUI angry vs friendly is supposed to be about the QTYPE used for truncated query names; the algorithm in section 3 does not depend on this choice, so I don't know why it is specifically the nasty algorithm. And section 2 seems to imply the existence of a nice algorithm but there isn't a specification of it. And why is the choice of QTYPE emotional, but the number of labels to add is not? Both section 5 and section 6 seem to be about performance, the problems and possible benefits, but only the possible benefits count as performance considerations. I think the question of how many labels to add on each iteration should be a core part of QNAME minimization, described in section 2. (I keep expecting the Oxford spelling "minimize"...) Tony. -- f.anthony.n.finchhttp://dotat.at/ Fitzroy: Northerly or northeasterly 3 to 5, becoming variable 4 or less in west, then southerly 5 or 6 in northwest. Moderate, occasionally rough at first in northeast. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Fwd: New Version Notification for draft-peetterr-dnsop-parent-side-auth-types-00.txt]
Brian Dickson wrote: > > This doesn't even address the significant challenges of developing a > method of passing the information from the domain owner (registrant) to > the parent name server (registry). The current mechanism of EPP, does > not even accommodate the DNS operator unless the DNS operator is also > the registrar. Yes, I was going to say something along these lines. Tangentially I suppose this is a case where the (common) EPP distinction between domain objects and host objects might (shock, horror) be useful: maybe we could in principle allow a DNS operator to manage information about their servers independently of the domains that they host. Tony. -- f.anthony.n.finchhttp://dotat.at/ Lands End to St Davids Head including the Bristol Channel: Northwest 5 to 7, veering north 4 to 6. Rough at first in southwest, otherwise slight or moderate. Showers. Good, occasionally moderate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Authoritative servers announcing capabilities
Paul Hoffman wrote: > On Sep 20, 2020, at 4:45 PM, Tony Finch wrote: > > > > Why can't you just send client-subnet in a request and look at the answer? > > That assumes that an attacker in the middle has not removed the answer. > The indicator that we used as an initial idea for the capability would > be signed, meaning that the resolver would expect a client subnet > response and could act if it didn't get one. OK, but how would the resolver's reaction differ? I.e. what problem is caused by resolvers lacking prior knowledge of client-subnet support? The more general solution for fixing traffic corruption is authenticated DoT, so it doesn't seem worth the effort to introduce a special mechanism to protect one EDNS option when DoT can do the job. Tony. -- f.anthony.n.finchhttp://dotat.at/ North Foreland to Selsey Bill: Southwesterly 3, increasing 4 or 5, then 6 or 7 later. Smooth becoming slight, then moderate later. Rain or showers later. Moderate or good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Authoritative servers announcing capabilities
Paul Hoffman wrote: > > At this point, the only information we defined in the draft is for doing > client subnet. Why can't you just send client-subnet in a request and look at the answer? Tony. -- f.anthony.n.finchhttp://dotat.at/ Selsey Bill to Lyme Regis: Northeast 3 or 4, becoming variable 3 or less. Slight or moderate, becoming smooth or slight. Fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
Ben Schwartz wrote: > On Tue, Aug 11, 2020, 5:51 PM Brian Dickson > wrote: > > > > I think the condition might be, "both in bailiwick and in the same zone" > > meaning "in bailiwick and not below a zone cut"? I don't think that makes sense - "bailiwick" is about glue. Maybe you could say "in the same zone (not below a zone cut)" and refer to RFC 1034 section 4.2 for the definition of a zone. > It seems to me that returning a (downward) delegation could actually be > useful. So why not include that? Additional section processing does not normally include referrals. That would be weird and new. I thought the point of the SVCB record was to appear to existing auth and recursive DNS servers as much as possible like a bog standard RR type, i.e. just wire and presentation format and a bit of normal additional section processing. Which is basically what the draft says now, though it unnecessarily respecifies additional section processing. Tony. -- f.anthony.n.finchhttp://dotat.at/ Mull of Kintyre to Ardnamurchan Point: Variable, mainly north or northwest, 2 to 4, occasionally 5 near the Mull of Kintyre and Tiree. Slight, occasionally smooth in shelter, becoming slight or moderate later. Fog patches developing. Moderate or good, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
Ben Schwartz wrote:
>
> > > If the server does not complete this procedure (e.g. due to response size
> > > limits), it MUST remove any SOA records from the Additional section.
> > > Recursive resolvers MAY use the presence of an SOA record in the
> > > Additional
> > > section to enable negative caching of the follow-up queries, as in
> > > {{?RFC2308}}.
> >
> > I'm not sure I understand this paragraph. Truncation is normally from the
> > end of the additional section backwards, so it is really weird to drop
> > records from the authority section first. SOA (start of authority) records
> > go in the authority section not the additional section
>
>
> In this procedure, "all returned records" for follow-up queries are added
> to the Additional section. Therefore, there could be SOA records in the
> Additional section.
I thought the target types were just A, , SVCB, so where does the SOA
come from?
> > The DNS doesn't allow a client to know that additional data doesn't exist
> > when it is omitted from a response. It sucks, but that's the way it is.
> >
>
> Yes; this proposal would change that in this case. If you think it won't
> work, I'd love to know why.
I can't see anything in the current SVCB draft that would change this.
There's simply no way to put a negative answer in an additional section
(without DNSSEC) - RFC 2308 relies on the context of the message header
and query sections and they don't exist for additional records.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
protect and enlarge the conditions of liberty and social justice
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
Ben Schwartz wrote:
>
> 1. If TargetName is not in-bailiwick and is not ".", terminate the procedure.
> 2. If SvcPriority is 0:
> * If TargetName is ".", terminate the procedure.
> * Otherwise, perform a SVCB "follow-up" query for TargetName and add all
> returned records, including any records added by this procedure.
> If any SVCB records were added, terminate.
> 3. Perform A and follow-up queries for TargetName (or for the owner name
> if
>TargetName is "."), and add all returned records.
I think the actual wording you want here is "in the same zone" not "in
bailiwick". The important thing you don't want is to require an auth
server to go out to the network to query for address records in a
delegated subdomain. The more subtle thing is happens with auth servers
that host zones from many customers: they want to avoid cross-zone
contamination in additional sections because a careless or malicious
customer may have set up a shadow zone for a domains whose NS records
point elsewhere.
The "bailiwick" term should only be used when discussing whether
delegations need glue or not. (See RFC 8499 and DJB's notes on
gluelessness that introduced the term http://cr.yp.to/djbdns/notes.html)
> If the server does not complete this procedure (e.g. due to response size
> limits), it MUST remove any SOA records from the Additional section.
> Recursive resolvers MAY use the presence of an SOA record in the Additional
> section to enable negative caching of the follow-up queries, as in
> {{?RFC2308}}.
I'm not sure I understand this paragraph. Truncation is normally from the
end of the additional section backwards, so it is really weird to drop
records from the authority section first. SOA (start of authority) records
go in the authority section not the additional section - the authority
section is all about gossiping zone cuts (i.e. SOA records) and nameserver
records. I don't understand how negative cacheing is relevant to a
positive response for a SVCB query.
The DNS doesn't allow a client to know that additional data doesn't exist
when it is omitted from a response. It sucks, but that's the way it is.
(This is why most SMTP software doesn't actually use the additional
section in MX responses.) You could in theory put a DNSSEC proof of
nonexistence in the additional section, but I don't know of any software
that will make intelligent use of it.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Southeast Iceland: Southeasterly veering southwesterly 3 to 5. Slight or
moderate. Fog patches, rain at times. Moderate or good, occasionally very
poor.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
Brian Dickson wrote: > > What I would suggest is the following, paraphrased (i.e. please clean it up > before using in the I-D, if you agree it's the right semantics): > >- In-bailiwick CNAME, SVCB, A, and records SHOULD be added (and for >CNAME and SVCB, in-bailiwick RDATA for those SHOULD also be iteratively >processed for inclusion) >- CNAME and SVCB records MUST be placed in the Answer section (because >of existing CNAME rules and because of RRTYPE match to the query) >- A and records MUST be placed in the Additional section (since >those would not match the query RRTYPE of SVCB) I've only skimmed this thread, so I might be repeating something that's already agreed... but I want to emphasize that a new RR type specification will have impossible interop problems if it tries to put records in the ANSWER section that aren't expected by existing DNS software. "Unexpected" means anything that isn't part of a CNAME or DNAME chain on the way from the original query name to an RRset of the query type. If a resolver queries for the owner of SVCB record (or a CNAME pointing at one) then anything related to the RDATA of the SVCB record(s) has to go in the ADDITIONAL section, or there will be sadness. It was a very long time before DNAME was usable and even within the last 10 years there was software that would choke on DNAME records in the ANSWER section that it didn't expect. Tony. -- f.anthony.n.finchhttp://dotat.at/ Shannon, Rockall: Variable 2 to 4. Moderate, occasionally slight. Drizzle. Moderate or poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-01.txt
I've had a look through and I have a few comments. Regarding smallest MTUs, I understand from Geoff Huston that it's common for IPv6 breakage to start at 1281 bytes. I would find it easier to understand the recommendations if the requirements for responder and requester were separated. In particular I don't know how a responder can do MTU discovery (though a simplified version might be possible). Here's my understanding of your recommendations: Requester: * should have a default EDNS buffer size no more than 1500 bytes (smaller than the 4096 that is currently typical, but bigger than the flag day recommendation) * should probe to discover the real MTU per destination, which can be less than the default, and use the discovered MTU for the EDNS buffer size in queries (resolvers already do this) * at the moment UDP timeouts don't cause fallback to TCP, but this should be added to the list of recovery tactics * requesters are supposed to guess (how?) the size of response before sending a query, so that they can skip UDP and go straight to TCP * should set the DONTFRAG option, though it's unlikely they are sending a query big enough for this to matter. (UPDATE clients need to care, though.) Responder: * should have a default UDP response size limit of no more than 1500 bytes (smaller than the 4096 that is currently typical, but bigger than the flag day recommendation) * should limit response sizes by based on the minimum of the request's EDNS buffer size and the server's limit (servers already do this) * should use minimal responses * should set the DONTFRAG option on responses * should listen for ICMP frag needed packets, and react by re-sending the response (which is embedded in the ICMP packet) with a TC bit set Network: * should send rate-limited ICMP frag needed messages to DNS servers when appropriate Tony. -- f.anthony.n.finchhttp://dotat.at/ Mull of Kintyre to Ardnamurchan Point: Southeast 4 to 6, occasionally 7 at first, then veering south 3 to 5 later. Slight or moderate, becoming moderate or rough near Tiree. Rain at times then fair, then showers later. Moderate or good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
John Levine wrote: > Paul Wouters wrote: > > > > Has anybody done a survey to find out how many TLD zones actually > > fits the description of "delegation-only"? > > I did some greppage, and found that all of the domains run by Verisign > and Nominet have signed non-glue A records. I think there are a lot of > TLDs run by others that are delegation only but they're mostly tiny > vanity domains. If there are RRSIG(A) records in .com and .net there must have been a policy change since 2010? There was a very subtle behaviour tweak implemented by Verisign for orphan glue aka host objects that have lost their domain objects: although the address records appear in the zone file, the name servers do not answer queries for them authoritatively: the addresses only appear in additional sections in referrals, and are not signed according to this: https://seclists.org/nanog/2010/Jan/298 I don't know if other nameservers implement the same behaviour. AFAIK it isn't possible to represent orphan glue in standard zone files or zone transfers, so I think this is an ATLAS special. Also despite having discussed this several times before I have not previously thought properly about how signing such a zone works! I suppose the assumption is that most resolvers are delegation-centric by default so they won't normally come back to validate the glue in the referral and won't discover it has been orphaned. So it usually won't matter if gtld-servers.net return an NSEC3 opt-out denial in response to a direct query for an orphaned glue record.. Maybe an NSEC3 opt-out covering these address records is enough to imply that they are orphan glue without needing new zone file or zone transfer syntax... Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking: West backing southeast 2 to 4, increasing 5 or 6 later. Slight or moderate. Occasional rain. Good, occasionally poor in north. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Question regarding RFC 8499
Paul Vixie wrote: > > that's why i've recommended we stop talking about "primary servers" or > "secondary servers", and instead talk about "transfer initiators" and > "transfer responders" Agreed, except that if you include notify as part of the zone transfer machinery, the question of who is the initiator gets murky. (An upstream starts a zone transfer process by notifying a downstream that it might want to make a transfer request... who is taking the initiative here?) So I prefer upstream and downstream, to match the flow of zone data. Tony. -- f.anthony.n.finchhttp://dotat.at/ Great Orme Head to the Mull of Galloway: West or northwest 3 or 4, occasionally 5 near Mull of Galloway, becoming variable 3 or less later backing south 4 or 5 later. Smooth or slight. Mainly fair. Mainly good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Question regarding RFC 8499
Joe Abley wrote: > > in my opinion we should find new words and not redefine or > overload the common meaning of primary and secondary. Yes. I don't really like primary/secondary because it implies there are only two categories when there aren't. For zone transfers, each server can (and often does) have both upstreams and downstreams, so the topology has multiple layers. Using "primary" and "secondary" in this context often implies things that aren't true. >From the outside point of view, an authoritative server can be used for several functions (public auth server listed in NS records, zone transfer server, update server, etc.) and whether it is primary or not is mostly irrelevant. Tony. -- f.anthony.n.finchhttp://dotat.at/ Faeroes: Southerly or southeasterly 2 to 4, occasionally 5 in west, becoming variable 3 or 4 later. Slight or moderate. Occasional rain. Moderate or good, occasionally poor later. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-00.txt
Mark Andrews wrote: > > Also I forget how Geoff was actually performing the test. Where any of > the responses greater than the advertised EDNS buffer size sent? Was > fragmentation introduced when the UDP response size was less that 1280? Just this morning I saw another report from Geoff mostly about IPv6 but with a fair amount of discussion about fragmentation https://www.potaroo.net/ispcol/2020-07/dns6.html Tony. -- f.anthony.n.finchhttp://dotat.at/ Lyme Regis to Lands End including the Isles of Scilly: Westerly or northwesterly 3 or 4, occasionally 5 near south Devon, becoming variable 2 to 4 later. Smooth or slight in east, slight or moderate in west. Fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
Joe Abley wrote: > > However, given that this document only points out an option that already > exist and doesn't actually recommend using a TLD versus any other > anchor, I don't think any of that matters. I think it's up to another > document to provide that kind of advice. It's hard to see any advantage > in shoe-horning that advice into this one -- and the chances of such a > document converging any time soon, regardless of venue. seem slim The existence of this document and the lack of any better advice will mean that the IETF recommendation is clear that the best setup for RFC 1918 networks is to use a reserved alpha-2 TLD. It isn't just pointing out something that's already there, it's a massive shove encouraging people to occupy this namespace. As opposed to the current situation where the implicit advice is that you should only use properly registered domain names, and reserved alpha-2 TLDs are only used by people like JP Mens in his test lab. https://jpmens.net/2010/09/28/performing-dynamic-dns-updates-on-your-dns/ Tony. -- f.anthony.n.finchhttp://dotat.at/ democracy, participation, and the co-operative principle ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
Brian Dickson wrote: > > Precisely because you want a non-TLD (we should remember this is NOT an > actual TLD), for a number of reasons: > >- You want to be able to limit the places any leaked traffic goes > - Currently this would be the Root Servers And any resolvers in between there and roaming users. > - The typical content of enterprisey internal-only names (the DNS >queries themselves) are sensitive in nature > - I have had the opportunity to view DITL data from ISP resolvers, > and the nature of these kinds of queries was unsettling > - In addition to leaking information, these names generally should > not have any presence in DNS caches, which makes them excellent > candidates > for easy poisoning These issues happen in exactly the same way whether you squat on a tld or use a private subdomain. The draft doesn't talk about random subdomains; instead it says that part of the point is to make names as short as possible. And our experience with telling people to use random parts of private address space (as in RFC 1918, and IPv6 GUA) is that they don't. Tony. -- f.anthony.n.finchhttp://dotat.at/ North Foreland to Selsey Bill: Southerly or southwesterly, becoming variable at times, 2 or 3, occasionally 4 until later. Smooth, occasionally slight. Fog patches for a time near shore. Moderate or good, occasionally very poor for a time near shore. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
Joe Abley wrote: > On Jun 15, 2020, at 18:46, Tony Finch wrote: > > > The intro to this draft talks about things like x- which has been > > deprecated since RFC 6648. It mentions some situationw where .test or > > ..invalid would seem to be the right things to use, but it doesn't say why > > not. It lists a bunch of TLDs that are being squatted by devices that > > ought to move to home.arpa instead, but doesn't say why we have given up > > on that idea after only a couple of years, or why we should expect them to > > move to ISO 3166 reserved codes when they haven't moved to home.arpa. > > I don't remember any text in the document that talked about people > changing what they are doing. Yes, that's why I pointed it out. The intro fairly explicitly says it's a replacement for .lan (etc.), but that raises questions about how this draft relates to other efforts to fix the .lan problem. I think people will read this draft as saying, don't do that home.arpa thing, don't do that .lan thing, do this. > Personally, I think the right advice for most people is that if you must > use private namespace you should anchor it at a domain name in the > global namespace that you control, so that your namespace is both > private and unique. Someone should write that document. I'll help, if > someone is interested. I agree that is the right advice. > But draft-arends-pitchfork-pitchfork-burn-the-witch doesn't provide that > kind of general advice; it provides specific advice for the case where > people have decided that a TLD is definitely needed by pointing out that Can't we continue to point out that they are wrong and there are better ways of solving their problems? I also appreciate that this draft is very clever, but speaking as an IOCCC winner, very clever things can also be things you should never do in production. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Mainly westerly or northwesterly, 3 to 5, occasionally 6 in southeast. Moderate, occasionally slight. Showers in north. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
Brian Dickson wrote: > Internal-only use is not only satisfied with non-delegated name spaces, it > actually is a much better fit for everything. Yes, I agree, but why does the point of non-delegation have to be a squatted collision-prone TLD, rather than a guaranteed collision-free subdomain of a properly registered domain? Tony. -- f.anthony.n.finchhttp://dotat.at/ Humber, North Thames: Variable 2 to 4. Smooth, occasionally slight. Fog banks. Moderate, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
Paul Vixie wrote: > > > I.e. the proposed use case is already widely deployed and known to be a > > bad idea. > > known by whom, and how? (got URL?) Gosh well I thought this was widely agreed folklore / common sense since the 1990s and I'm not in the habit of collecting links to essays on "why X is a bad idea" when it seems from my perspective that approximately nobody writes essays like that because X is obviously a bad idea... :-) But, we know that overlapping name spaces and address spaces are a nightmare for mergers and acquisitions. It's incompatible with private interconnects, such as organizations collaborating without mergeing, or home-to-home VPNs. We know that non-unique namespaces are incompatible with the web security model. We know that it's incompatible with PKIX. (You can do private x.509 but not public.) We know it's incompatible with DNSSEC. (You can set up a private root, but then we're back to splendid isolation and arcane technical expertise.) Overall it scuppers much of the protocols that support end-to-end connectivity and security. And the breakage is unnecessary because we know there are straightforward alternatives that avoid the problems. [ I am maybe exaggerating a bit about the 1990s, because back then, when Microsoft Small Business Server was encouraging everyone and their dog to squat on .local, domain names were 10x more expensive than now and 100x more difficult to obtain, so they had a reasonable excuse, but it was still terrible. ] Tony. -- f.anthony.n.finchhttp://dotat.at/ Channel Islands: South to southeast 2 to 4, becoming variable 1 to 3 by early afternoon, then northwest 1 to 3 by midnight. Smooth or slight. Scattered thundery showers, mainly near French coasts, risk of mist or fog patches, mainly in the north of the area. Moderate or good, occasionally poor, perhaps locally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
Paul Vixie wrote: > > there are perhaps more than three, and some might not be yet known by those > who will > want them. the reason why some part of the DNS namespace should be reserved > in the > form, "shall never be allocated by IANA", is not because we cannot think of a > good > enough and present cause why such a thing may be desirable. Fair enough, but what you are suggesting seems to be quite different from what this draft is suggesting. You seem to be talking about reserving for future use, or for lab environments that never connects to any other part of the Internet, whereas this draft is just suggesting that everyone should use these ISO 3166 reserved codes as a 192.168 free-for-all instead of .lan or .home or whatever they are currently squatting on. I.e. the proposed use case is already widely deployed and known to be a bad idea. The intro to this draft talks about things like x- which has been deprecated since RFC 6648. It mentions some situationw where .test or ..invalid would seem to be the right things to use, but it doesn't say why not. It lists a bunch of TLDs that are being squatted by devices that ought to move to home.arpa instead, but doesn't say why we have given up on that idea after only a couple of years, or why we should expect them to move to ISO 3166 reserved codes when they haven't moved to home.arpa. Tony. -- f.anthony.n.finchhttp://dotat.at/ fight poverty, oppression, hunger, ignorance, disease, and aggression ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
Paul Vixie wrote: > On Monday, 15 June 2020 17:58:42 UTC Tim Wicinski wrote: > > > > or since domains are cheap, why not buy a new domain, and use that for the > > namespace? > > that makes internet viral, and private communications require global > allocations for no necessary reason. the above quite describes centralization > for the sake of centralization. nothing should be centralized unless there's > no other way to do what needs doing. > > reserving a corner of the namespace for decentralized operations makes sense. There are perhaps three contexts that you might want a private namespace: * enterprisey setups * home setups * splendid isolation For both the enterprise and home case, you're probably going to want to do things beyond the DNS that are much easier if you're part of a global namespace - TLS certs are probably the main one. For the enterprise case, getting a suitable domain is normal. For the home case, it would make sense for manufacturers of home gateways / access points to allocate a per-customer subdomain. Then you can have IPv6 prefix delegation and managed access to your devices at home without everything being proxied via some cloud server. (I can dream?) For splendid isolation, you're already committing to setting up your own CA and distributing keys, so you can probably set up your own fake root zone and whatever else. I don't think it's something that should be encouraged as a standard thing to do, though. How could it be made to work usefully for non-technical home users? Tony. -- f.anthony.n.finchhttp://dotat.at/ Lands End to St Davids Head including the Bristol Channel: Variable 2 to 4. Slight in west, smooth in east. Showers, thundery at times. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
Tim Wicinski writes: > This starts a Call for Adoption for draft-arends-private-use-tld I think this is cute / clever, but a very bad idea. Experience from IPv4 and IPv6 private use areas shows that there will be collisions and they will be painful. The first line of the abstract is wrong. Every properly registered domain name is a private-use namespace. The desire for shortness is why the DNS has search paths and unqualified domain names. Tony. -- f.anthony.n.finchhttp://dotat.at/ East Sole: Cyclonic becoming northwesterly, 3 to 5. Slight, occasionally moderate. Thundery showers. Good, occasionally moderate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CNAME chain length limits
dagon wrote:
>
> -- Tests for ("improper") horizontal vs. vertical CNAMEs. Some
> recursive speakers fail; some complain ("BAD (HORIZONTAL)
> REFERRAL", but answer), and some follow without complaint.
Can you explain what these are, please?
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Forth, Tyne, Dogger: Variable mainly south 2 to 4. Smooth or slight. Mainly
fair. Good, occasionally poor.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] unsolicited HTTPSSVC responses
Paul Hoffman wrote: > > Add where in the response? In the Answer section or in the Additional > section? The semantics and usefulness are wildly different for those > two. We learned from DNAME that a lot of DNS software gets very upset if there are unexpected records in the answer section. If you want to add additional records they have to go in the additional section. Tony. -- f.anthony.n.finchhttp://dotat.at/ Lundy, Fastnet: Easterly 3 to 5, veering southeasterly 5 or 6 in southwest Fastnet. Slight or moderate. Fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] definitions of "public DNS Service"
I think despite what Paul H. said this is already covered in RFC 8499: Open resolver: A full-service resolver that accepts and processes queries from any (or nearly any) client. This is sometimes also called a "public resolver", although the term "public resolver" is used more with open resolvers that are meant to be open, as compared to the vast majority of open resolvers that are probably misconfigured to be open. Open resolvers are discussed in [RFC5358]. Paul V. is right that "public" is not a good term in this context. IIRC it was introduced as part of a product name to make it sound less monopolistic. And just "DNS" is unhelpfully unclear about whether it's a recursive or authoritative service. Tony (whose random .sig seems to be trolling). -- f.anthony.n.finchhttp://dotat.at/ public services of the highest quality ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient...
Shumon Huque wrote: > > Here's the announcement of that change from Verisign (January 2010): > > https://lists.dns-oarc.net/pipermail/dns-operations/2010-January/004841.html That's the one! - point 2 was what I was thinking of. The way they handle glue under domains that are on hold is very tricky. And I think not possible with standard zone files and zone transfers... Tony. -- f.anthony.n.finchhttp://dotat.at/ Southeast Iceland: Northerly or northeasterly 6 to gale 8, perhaps severe gale 9 later. Moderate or rough, becoming very rough or high later. Fog patches at first in north, otherwise rain. Moderate, occasionally very poor at first in north. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient...
John R Levine wrote: > > A week or two ago I scannned TLD zone files to see how many signed A and > records there were. Quite a lot, most looks to be orphan glue in Afilias > zones that they didn't delete after the registered zone went away. I vaguely remember a policy change in .com and .net years ago when they stopped including orphan glue in the zones. Was this to do with prep work for DNSSEC? I'm slightly surprised .org didn't follow suit. Tony. -- f.anthony.n.finchhttp://dotat.at/ Rattray Head to Berwick upon Tweed: Southwest 5 to 7, increasing gale 8 at times later. Moderate or rough. Rain then showers. Good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] New Version Notification for draft-fanf-dnsop-sha-ll-not-00.txt (fwd)
Paul Hoffman wrote: > This confuses a harm purposely caused by authorities (in this case, the > IETF), with self-harm (in this case, a zone owner who didn't hear about > the importance of doing an algorithm rollover, or did hear but didn't > care). They are quite different. Also I think you have misunderstood an important point: the aim of my draft is to disable validation for SHA-1 after it is no longer used for signing. The first guess at a strategy might be a mess, but that's OK because this is just a draft. So please stop accusing me of trying to hurt people. It's extremely rude, especially when you repeat the accusation after I told you I am trying to avoid it. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Northeasterly 4 or 5 in southeast, otherwise variable 3 or 4. Moderate or rough. Fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] New Version Notification for draft-fanf-dnsop-sha-ll-not-00.txt (fwd)
Paul Hoffman wrote: > On Mar 9, 2020, at 6:46 PM, Tony Finch wrote: > > Which is why the timetable aims to stop the use of SHA-1 for signing > > before it stops the use of SHA-1 for validating, assuming > > optimistically that we actually have 2 years available. (I fear we > > don't.) > > Who is "we" there? Mainly, people who don't want DNSSEC to be open to criticism for using broken cryptography. > > WRT updating RFC 8624, my hope is that updated implementation > > requirements will encourage better tools to make it easier to upgrade > > from SHA-1 before SHA-1 becomes useless. My initial suggestions are > > probably ham-fisted, but for software that is on an annual cycle of > > feature releases there isn't time for a multi-stage deprecation. I > > don't think there's any point addressing a draft to operators if the > > tooling still encourages the use of SHA-1. > > Then consider writing a draft that strongly discourages implementations > from encouraging or even being neutral about algorithms with SHA-1. That's what I tried to do. Tony. -- f.anthony.n.finchhttp://dotat.at/ Rockall, Malin, Hebrides, Bailey: Cyclonic at first in north Bailey, otherwise westerly or southwesterly 6 to gale 8. Very rough, occasionally high except in Malin. Rain then squally showers. Moderate or good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-fanf-dnsop-sha-ll-not-00.txt (fwd)
Paul Wouters wrote: > > Obsoleting really takes time. And the path is to first stop producing > SHA1 signatures, and once that number goes down, to start discouraging > consuming SHA1 signatures. If you immediately say MUST NOT for validating, > you are making 2211449 + 287467 = 2.5M domains more insecure. That would > be very irresponsible, and serve no real purpose. Saying "start of 2022" > might be okay, but might not be okay. We don't know yet. That is why RFC > 8624 does not put in specific dates. We need to push the market, but > not demand unrealistic speeds. If we do that, people will simply start > ignoring the RFC recommendations. Right. I don't think we're pushing hard enough, so I'm trying to get suggestions for how we can do better. > The document spells out a big doom day scenario, and then in section > 5.4.1 admits that, oh btw, if you don't share private keys with other > zones, then you don't really have an issue. There are several other dangerous situations. If you have shared hosting within a zone, you have an issue. If you are a large enterprise you have a privilege escalation issue. If you are a TLD with weak DS syntax checks, you have an issue. (I spelled out a privilege escalation attack in more detail in https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html) > But what really needs to happen is that we need to reduce the number of > SHA1 signatures present. We could push the signing software vendors to > refuse generating new DNSKEY's KSK's that use SHA1. This might delay a > KSK rollover unexpectedly, but it won't cause any outages or regressions > to insecure zones. And that process already mostly involves a human > interaction for an updated DS anyway. Slowing that down won't really > do any harm. It would give those using SHA1 a nudge to look at doing an > algorithm rollover for their new KSK instead. Similarly, we could nudge > TLDs to stop accepting SHA1 based DS records, or for those TLDs that > generate their own DS records, push them to no longer publish SHA1 > based DS records. Those are good ideas, thanks. WRT DS records, are you talking about DNSKEY algorithm types or DS digest types? I'm not so worried about digest type 1 because DS digests need to be secure against preimage attacks and SHA-1 is still OK in that respect. (And digest types are easier to upgrade.) > Which brings me to my second point, upgrading. Moving away from SHA1 > involves an algorithm rollover. A lot of currently deployed signers run > on software that is a few years old. For instance a few year old bind or > opendnssec does not even support an algorithm rollover. I believe the > main reason we still see so muc SHA1, is that people and their software > are not ready to do an algorithm rollover. And if they are not ready, > publishing a new RFC that mandates such a change will just be ignored. > We need to work on our tools and documentation to give confidence to > people that an algorithm rollover is easy Well, we had better get on with that quickly then. I think BIND is not as bad as you say: my colleagues have done an algorithm rollover with 9.10 which is over 5 years old. Tony. -- f.anthony.n.finchhttp://dotat.at/ Shetland Isles: South or southeast 5 or 6, veering west or southwest 5 to 7, occasionally gale 8 later. Moderate at first in sheltered east, otherwise rough or very rough. Occasional rain, squally showers later. Good occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] New Version Notification for draft-fanf-dnsop-sha-ll-not-00.txt (fwd)
Paul Hoffman wrote: > > This draft is about discouraging people from signing with SHA-1 by > directly harming them (implementations that will no longer be able to > validate their signatures). While threats of direct harm are probably > effective at getting to a desired outcome, they do not represent the way > the IETF normally does its work. (I'm happy about that.) I tried to address this in the security considerations section. The aim is to avoid harm, specifically the harm of having to suddenly and surprisingly disable SHA-1 validation via a mass CVE and security patch when a collision attack improvement comes along that makes it dangerously misleading to stick an AD bit on an answer from a SHA-1 zone. Which is why the timetable aims to stop the use of SHA-1 for signing before it stops the use of SHA-1 for validating, assuming optimistically that we actually have 2 years available. (I fear we don't.) WRT updating RFC 8624, my hope is that updated implementation requirements will encourage better tools to make it easier to upgrade from SHA-1 before SHA-1 becomes useless. My initial suggestions are probably ham-fisted, but for software that is on an annual cycle of feature releases there isn't time for a multi-stage deprecation. I don't think there's any point addressing a draft to operators if the tooling still encourages the use of SHA-1. This problem should have been dealt with years ago, and now it needs to be treated as an emergency. Tony. -- f.anthony.n.finchhttp://dotat.at/ fight poverty, oppression, hunger, ignorance, disease, and aggression ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] New Version Notification for draft-fanf-dnsop-sha-ll-not-00.txt (fwd)
The aim of this is to deprecate SHA-1 algorithms 5 and 7 more vigorously. I've put in a fairly specific timetable for sake of argument, basically to set up the death of SHA-1 as next year's DNS "flag day", unless some clever cryptanalysis forces it to happen sooner. I'm afraid it's a rough first pass: I haven't given it a read-through and cleanup, because watching Flash Gordon was more fun. Tony. -- f.anthony.n.finchhttp://dotat.at/ ALL CREATURES WILL MAKE MERRY UNDER PAIN OF DEATH -- Forwarded message -- Date: Mon, 09 Mar 2020 15:55:05 -0700 From: internet-dra...@ietf.org To: Tony Finch Subject: New Version Notification for draft-fanf-dnsop-sha-ll-not-00.txt A new version of I-D, draft-fanf-dnsop-sha-ll-not-00.txt has been successfully submitted by Tony Finch and posted to the IETF repository. Name: draft-fanf-dnsop-sha-ll-not Revision: 00 Title: Hardening DNSSEC against collision weaknesses in SHA-1 and other cryptographic hash algorithms Document date: 2020-03-09 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-fanf-dnsop-sha-ll-not-00.txt Status: https://datatracker.ietf.org/doc/draft-fanf-dnsop-sha-ll-not/ Htmlized: https://tools.ietf.org/html/draft-fanf-dnsop-sha-ll-not-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-fanf-dnsop-sha-ll-not Abstract: DNSSEC deployments have often used the SHA-1 cryptographic hash algorithm to provide authentication of DNS data. This document explains why SHA-1 is no longer secure for this purpose, and deprecates its use in DNSSEC signatures. This document updates RFC 8624. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] status of the aname and svcb/httpsvc drafts
Anthony Eden wrote: > My intention with the original draft I wrote > https://tools.ietf.org/html/draft-dnsop-eden-alias-rr-type-00 was to > provide just the basics. If anyone is interested we can always try to > resuscitate that draft at some point. Thanks for that :-) Unfortunately it requires recursive lookups by authoritative servers, which isn't possible for many implementations or for many deployments (in particular signed zones where the auth servers cannot have the private keys). And (as I've been arguing) dynamic lookups aren't really necesasry for ANAME to work. Tony. -- f.anthony.n.finchhttp://dotat.at/ Fair Isle, Faeroes, Southeast Iceland: Mainly easterly 7 to severe gale 9, occasionally storm 10 later, but cyclonic 3 for a time in southwest. Very rough or high. Rain or wintry showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] status of the aname and svcb/httpsvc drafts
Erik Nygren wrote: > I don't follow how this works for the non-trivial static case. > You have two authoritative parties, one for the authoritative zone > and one authoritative for the ANAME target. > Both are operated by different entities. > > The logic and policy for the ANAME target (involving geo-ip, GSLB, etc) > is often highly dynamic and proprietary. How does this get conveyed > from the authorities for the ANAME target to the authorities for the zone > containing the ANAME? This is where we seem to get stuck. I imagine a boiled-dry draft would leave this unspecified, allowing implementations to be as lazy or eager as they want. I think this enthusiasm to accurately reproduce all the crazy DNS tricks is doomed to failure, and not actually necessary. If a domain owner really truly wants to spread their domain with Brand X secret sauce they can get Brand X to host it, and if they can live with a cheap 3rd party ANAME knock-off then that can be done much more simply. Tony. -- f.anthony.n.finchhttp://dotat.at/ Fisher, German Bight: Cyclonic mainly southwesterly, becoming westerly, 4 to 6. Slight or moderate becoming moderate or rough. Wintry showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] status of the aname and svcb/httpsvc drafts
Vladimír Čunát wrote: > > The current ANAME draft specifies new behavior for resolvers, and there > I'd expect even slower overall upgrades/deployment than in browsers. From my point of view that was the least important part of it, an optional extra that might help out CDNs some time in the future, and not necessary for deployment. Existing ANAME implementations work fine without it. The ANAME draft is far too complicated. I tried to simplify it but in retrospect I didn't go far enough. There might still be some value in an ANAME draft that simply specifies the syntax of the record, just to provide portability of zone files between implementations that currently have non-standard ANAME or ALIAS records. In this boiled-dry draft, ANAME would have absolutely no special normative semantics, just an informative description of the relationship between the sibling and target address records with no description of how that should be achieved. (Note a domain might have more than one ANAME, for existing implementations that support round-robin ANAMEs.) So the codepoint could be allocated via expert review rather than standards action. Tony. -- f.anthony.n.finchhttp://dotat.at/ strengthen the democratic process and ensure that there is a just and representative system of government___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] status of the aname and svcb/httpsvc drafts
Bob Harold wrote: > Just my opinion, but I would like to focus on HTTPSSVC first, for a quick > win. Then work on ANAME - it might not be used much anytime soon, ANAME has been widely deployed in various forms for many years. Tony. -- f.anthony.n.finchhttp://dotat.at/ Dover, Wight, Portland, Plymouth: West 5 to 7, increasing gale 8 later, occasionally severe gale 9 in Portland and Plymouth, and perhaps in Wight. Moderate or rough, becoming rough or very rough except in Dover, then becoming very rough or high later in west Portland and in Plymouth. Squally showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] status of the aname and svcb/httpsvc drafts
Evan Hunt wrote:
>
> CNAME at the apex wasn't really the problem. Getting browsers to display
> content from the right CDN server was the problem.
My interest in ANAME is basically nothing to do with CDNs. I want my users
to be able to configure aliases by name or address without having to deal
with incomprehensible restrictions. ("It's always a DNS problem") Ideally
they should be able to configure aliases by name so that those responsible
for the server can move it around without having to reconfigure ridiculous
numbers of aliases.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Portland, Plymouth: West or southwest 6 to gale 8. Rough or very rough. Rain
and drizzle. Moderate or poor.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-resolver-information-01.txt
Niall O'Reilly wrote: > > I think that a clearer expression of the first case might be > > any server that can act as both an authoritative server and a recursive > resolver MUST NOT answer queries that are defined in this protocol > whenever it is acting as an authoritative server. > > If this still seems to leave a contradiction, it may be worthwhile to > view the distinction as a property of the transaction, rather than of > the "portion of the server". The server, if it receives a query for > which it determines that an authoritative answer is appropriate, must > not answer as if it were a recursive resolver. The conditions for special recursive-only answers are queries with RD=1 that get responses with RA=1. (You might be able to allow queries with RD=0 but I don't know if iterative clients that happen to be allowed RA=1 are likely to be confused by these answers.) Tony. -- f.anthony.n.finchhttp://dotat.at/ partnership and community in all areas of life ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] SHA-1 and DNSSEC validation
I've posted a follow-up to my article last month about SHA-1 chosen prefix collisions and DNSSEC. This discusses DNSSEC validation: https://www.dns.cam.ac.uk/news/2020-02-14-sha-mbles.html Summary: DNSSEC validators should continue to treat SHA-1 signatures as secure until DNSSEC signers have had enough time to perform algorithm rollovers and eliminate SHA-1 from the vast majority of signed zones. Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire, South Utsire, Forties, Cromarty: Southerly 6 to gale 8, occasionally severe gale 9 except in South Utsire, veering southwesterly 4 to 6 for a time. Rough or very rough, occasionally moderate. Rain or showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Unknown DNS RDATA type presentation syntax vs. e.g. TXT records?
Dick Franks wrote: > > The troublesome length bytes can be avoided by (ab)using a generic URI > RR instead: Indeed :-) The reason I wanted to make the attack work with TXT was the example scenario targeted ACME dns-01, so it's more pointed if we imagine the attacker has very limited access to update the zone. Also it's a fun opportunity to try smuggling arbitrary binary data through a parser that you might not expect would allow it. Tony. -- f.anthony.n.finchhttp://dotat.at/ Shannon: Westerly 7 to severe gale 9, occasionally storm 10 at first in north, backing southerly 4 to 6 later. High or very high, occasionally very rough later. Occasional rain or showers. Moderate, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Unknown DNS RDATA type presentation syntax vs. e.g. TXT records?
Viktor Dukhovni wrote: > > I was therefore surprised to find that BIND 9.14 refuses load zone files > with TXT records in the generic form, for example named-checkzone does > not accept: > > example.org.IN TXT \# 4 deadbeef The long version of Mark's message is that a TXT record consists of an overall RDLENGTH (which is the number after the \#) and then each string in the RDATA is prefixed with its own length byte. So the wire format of TXT "\222\173\190\239 is TYPE16 \# 5 04deadbeef The multiple strings and nested lengths in TXT records are a curiously gratuitous complication. When I was working out how a SHA-1 attack could work with TXT records, (https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html) one of the problems was that the collision blocks in the best attack so far are 588 bytes, which is too big to fit into a single TXT string. So there will be length bytes inside the collision blocks which can't easily be controlled by the attacker. The solution is to append 255 zero bytes which is enough to fill the tail end of any string specified by the last length byte in the collision blocks, and any excess zero bytes get treated as a sequence of empty strings. Tony. -- f.anthony.n.finchhttp://dotat.at/ Dogger, Fisher, German Bight: West 7 to severe gale 9, decreasing 6 for a time. Rough or very rough. Squally wintry showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rrserial as a path to fame and fortune (was: Adoption of new EDNS opcode "rrserial")
Shane Kerr wrote: > > * Returning the entire signed SOA in the additional section, rather than > just the serial in an EDNS record (for DNSSEC validation purposes). I think it would be more traditional to put it in the AUTHORITY section :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ Lough Foyle to Carlingford Lough: Southwest 5 to 7. Slight or moderate for a time in east, otherwise moderate or rough, occasionally very rough in north. Occasional rain or drizzle. Moderate or good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [secdir] Secdir review of draft-ietf-dnsop-rfc2845bis-06
Warren Kumari wrote: > Great, I'll take the silence as wide endorsement, and ask that the > authors update the document with this text (or something similar...) - > I'll then start IESG Eval. PS. wrt "collisions", might be worth adding informative references to https://sites.google.com/site/itstheshappening/ https://shattered.io/ https://sha-mbles.github.io/ Tony. -- f.anthony.n.finchhttp://dotat.at/ Lough Foyle to Carlingford Lough: South or southwest 3 or 4, increasing 5 or 6 later. Smooth or slight at first in southeast, otherwise slight or moderate, occasionally rough in north. Occasional rain or drizzle, mainly in north. Moderate or good, occasionally poor in north. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [secdir] Secdir review of draft-ietf-dnsop-rfc2845bis-06
Warren Kumari wrote: > > I don't think that it is realistic to deprecate SHA-1 in TSIG for the > foreseeable future, but stronger recommendations about moving to > SHA-256 might be in order. Yes. > There is already some text: For context, the preceding paragraph says: The only message digest algorithm specified in the first version of these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321], [RFC2104]). Although a review of its security [RFC6151] concluded that "it may not be urgent to remove HMAC-MD5 from the existing protocols", with the availability of more secure alternatives the opportunity has been taken to make the implementation of this algorithm optional. >The use of SHA-1 [FIPS180-4], [RFC3174], (which is a 160-bit hash as >compared to the 128 bits for MD5), and additional hash algorithms in >the SHA family [FIPS180-4], [RFC3874], [RFC6234] with 224, 256, 384, >and 512 bits may be preferred in some cases. This is because >increasingly successful cryptanalytic attacks are being made on the >shorter hashes. I think the quoted paragraph should say something like: [RFC4635] added mandatory support in TSIG for SHA-1 [FIPS180-4], [RFC3174]. SHA-1 collisions have been demonstrated so the MD5 security considerations apply to SHA-1 in a similar manner. Although support for hmac-sha1 in TSIG is still mandatory for compatibility reasons, existing uses should be replaced with hmac-sha256 or other SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234]. Tony. -- f.anthony.n.finchhttp://dotat.at/ German Bight: West veering northwest 4 or 5. Slight or moderate. Occasional drizzle. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec
Matthijs Mekking wrote: > I am not sure how they executed the algorithm rollover precisely. > Particularly, were there ever two DS records in the root zone with > different algorithms for these zones? I can answer that :-) Algorithm rollovers have to be double-KSK rollovers because DS records have to have a subset of the algorithms of the DNSKEY records. Having both algorithms in the DS record can only slow down the rollover so it's hard to think of situations where it would make sense (other than Shumon's multi-provider disagreement!) [ For normal KSK rollovers I think double-DS is slightly better since it allows smaller DNSKEY RRset sizes, tho it requires more parent zone updates. ] --- root.db +++ root.db @@ -1,4 +1,4 @@ -.86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2018082001 1800 900 604800 86400 +.86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2018082002 1800 900 604800 86400 .518400 IN NS a.root-servers.net. .518400 IN NS b.root-servers.net. .518400 IN NS c.root-servers.net. @@ -2096,7 +2096,7 @@ br. 172800 IN NS d.dns.br. br. 172800 IN NS e.dns.br. br. 172800 IN NS f.dns.br. -br. 86400 IN DS 45673 5 2 14369AD309CC59FD59C1A422BA93B71F2C522BF3672C2E067B2C53F5 3AE522DF +br. 86400 IN DS 2471 13 2 5E4F35998B8F909557FA119C4CBFDCA2D660A26F069EF006B403758A 07D1A2E4 a.dns.br.172800 IN A 200.160.0.10 a.dns.br.172800 IN 2001:12ff::10 b.dns.br.172800 IN A 200.189.41.10 --- root.db +++ root.db @@ -1,4 +1,4 @@ -.86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017121400 1800 900 604800 86400 +.86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017121401 1800 900 604800 86400 .518400 IN NS a.root-servers.net. .518400 IN NS b.root-servers.net. .518400 IN NS c.root-servers.net. @@ -11638,6 +11638,7 @@ ns3.pknic.net.pk.172800 IN A 199.192.75.54 root-s.pknic.pk. 172800 IN A 119.81.34.90 pl. 172800 IN NS a-dns.pl. +pl. 172800 IN NS b-dns.pl. pl. 172800 IN NS c-dns.pl. pl. 172800 IN NS d-dns.pl. pl. 172800 IN NS e-dns.pl. @@ -11648,6 +11649,8 @@ pl. 86400 IN DS 14075 8 2 4D12B53E0A179C5E51719F606FC429EA03F444CDF5370FBBEEB6ECEB 21E99F2B a-dns.pl.172800 IN A 194.181.87.156 a-dns.pl.172800 IN 2001:a10:121:1::156 +b-dns.pl.172800 IN A 192.195.72.53 +b-dns.pl.172800 IN 2001:7f9:c::53 c-dns.pl.172800 IN A 93.190.128.146 c-dns.pl.172800 IN 2a02:38:14::146 d-dns.pl.172800 IN A 81.15.133.186 @@ -13124,7 +13127,7 @@ se. 172800 IN NS i.ns.se. se. 172800 IN NS j.ns.se. se. 172800 IN NS x.ns.se. -se. 86400 IN DS 59747 5 2 44388B3DE9A22CAFA8A12883F60A0F984472D0DFEF0F63ED59A29BE0 18658B28 +se. 86400 IN DS 59407 8 2 67A8E06FCEFDD9397F77F26C41ADE4EC142F299BCFA1827F0EF8FD87 F2F63022 nsa.netnod.se. 172800 IN A 194.58.192.33 nsa.netnod.se. 172800 IN 2a01:3f1:33::53 nsp.netnod.se. 172800 IN A 194.58.198.33 Tony. -- f.anthony.n.finchhttp://dotat.at/ Cape Wrath to Rattray Head including Orkney: Mainly westerly or southwesterly 3 or 4, occasionally 5 in north. Smooth or slight in east, moderate or rough in north, occasionally very rough at first in far north. Fair then occasional rain or drizzle, fog patches developing in north. Moderate or
Re: [DNSOP] SHA-1 chosen prefix collisions and DNSSEC
Tony Finch wrote: > I have written a blog post with my understanding of the implications of > the SHAmbles attack for DNSSEC. > > https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html I've updated that with a correction about the SHA-1 input block size, but that doesn't affect the overall conclusions. Tony. -- f.anthony.n.finchhttp://dotat.at/ Gibraltar Point to North Foreland: Northwesterly 4 or 5, backing southerly or southwesterly 5 to 7, perhaps gale 8 later. Slight or moderate, smooth in Thames estuary. Mainly fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] SHA-1 chosen prefix collisions and DNSSEC
I have written a blog post with my understanding of the implications of the SHAmbles attack for DNSSEC. https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html Conclusions from the article: Whenever a DNS zone is signed with a SHA-1 DNSKEY algorithm it is vulnerable to chosen prefix collision attacks. This is a problem when a zone accepts updates from multiple parties, such as: TLDs enterprises hosting providers It is also a problem when a key is re-used by multiple zones. Zones using algorithm numbers 7 or less should be upgraded. The recommended algorithms are 13 (ECDSAP256SHA256) or 8 (RSASHA256, with 2048 bit keys). For extra protection against chosen prefix collision attacks, zones should not share keys, and they should have separate ZSKs and KSKs. DNSSEC zone signing software should provide extra protection against chosen prefix collisions by adding more randomness to the inception and expiration times in RRSIG records. Software implementing CDNSKEY and CDS checks must ensure that the records are properly signed by a KSK, not just a ZSK. Top-level domain registry software must not accept over-sized DS records. Tony. -- f.anthony.n.finchhttp://dotat.at___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1
The third paragraph of the abstract suggests this is relevant to DNSSEC RSASHA1: https://eprint.iacr.org/2020/014 > SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and > Application to the PGP Web of Trust > Gaëtan Leurent and Thomas Peyrin > Abstract: The SHA-1 hash function was designed in 1995 and has been > widely used during two decades. A theoretical collision attack was first > proposed in 2004 [WYY05], but due to its high complexity it was only > implemented in practice in 2017, using a large GPU cluster [SBK+17]. > More recently, an almost practical chosen-prefix collision attack > against SHA-1 has been proposed [LP19]. This more powerful attack allows > to build colliding messages with two arbitrary prefixes, which is much > more threatening for real protocols. > In this paper, we report the first practical implementation of this > attack, and its impact on real-world security with a PGP/GnuPG > impersonation attack. We managed to significantly reduce the complexity > of collisions attack against SHA-1: on an Nvidia GTX 970, > identical-prefix collisions can now be computed with a complexity of > 2^61.2 rather than 2^64.7, and chosen-prefix collisions with a complexity > of 2^63.4 rather than 2^67.1. When renting cheap GPUs, this translates to > a cost of 11k US$ for a collision, and 45k US$ for a chosen-prefix > collision, within the means of academic researchers. Our actual attack > required two months of computations using 900 Nvidia GTX 1060 GPUs (we > paid 75k US$ because GPU prices were higher, and we wasted some time > preparing the attack). > Therefore, the same attacks that have been practical on MD5 since 2009 > are now practical on SHA-1. In particular, chosen-prefix collisions can > break signature schemes and handshake security in secure channel > protocols (TLS, SSH). We strongly advise to remove SHA-1 from those type > of applications as soon as possible. We exemplify our cryptanalysis by > creating a pair of PGP/GnuPG keys with different identities, but > colliding SHA-1 certificates. A SHA-1 certification of the first key can > therefore be transferred to the second key, leading to a forgery. This > proves that SHA-1 signatures now offers virtually no security in > practice. The legacy branch of GnuPG still uses SHA-1 by default for > identity certifications, but after notifying the authors, the modern > branch now rejects SHA-1 signatures (the issue is tracked as > CVE-2019-14855). Tony. -- f.anthony.n.finchhttp://dotat.at/ The Minch: South veering southwest, then west later, 7 to severe gale 9, occasionally storm 10 at first. Rough or very rough, but high in far north and in far south. Rain then squally showers. Moderate or poor, occasionally good.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and DNAME
John Levine wrote: > > PS: I'm also coming to the conclusion that if you think DNAME solves > your problem, and your problem isn't the arcane IPv6 rDNS renumbering > for which it was invented, you don't understand DNAME. We're using it to reduce the number of IPv4 reverse DNS zones, for which it works nicely. Basically, classless reverse DNS for short prefixes. https://www.dns.cam.ac.uk/domains/reverse/ Tony. -- f.anthony.n.finchhttp://dotat.at/ Lundy, Fastnet, Irish Sea: North 5 to 7, occasionally gale 8 at first, except in Irish Sea. Moderate or rough, becoming slight in northern Irish Sea. Showers. Good, occasionally moderate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and DNAME
Shane Kerr wrote: > On the other hand, it seems unlikely that any resolver actually sends > ANY queries to authoritative servers. This happens when the resolver's cache doesn't have an entry for the name, so the resolver sends the ANY query to the authoritative servers. It's rare because ANY queries are rare, but it's easy to make it happen when you want it to. > We have chosen to perform CNAME synthesis for ANY queries that match a DNAME > subtree, based on the logic that if CNAME is special when added by hand then > it is probably also special when synthesized. That's correct. Tony. -- f.anthony.n.finchhttp://dotat.at/ Lundy, Fastnet, Irish Sea: North 5 to 7, occasionally gale 8 at first, except in Irish Sea. Moderate or rough, becoming slight in northern Irish Sea. Showers. Good, occasionally moderate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On obsoleting DNSSEC RFCs; Example from RFC 4035 (2)
Дилян Палаузов wrote: > > Does it make sense to generate RRSIG for the ZSK and why 1/3 of the > DNSSEC enabled sites, maintaining DNSSEC enabled DNS servers do it? This is at least partly a BIND peculiarity. By default it signs the DNSKEY RRset with all the keys. You can tell `named` to sign only with the KSK using the `dnssec-dnskey-kskonly` option, and `dnssec-signzone` with the `-x` option. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty, Forth, Tyne, Dogger: North or northwest 3 to 5 increasing 6 or 7, perhaps gale 8 later, in Cromarty, Forth and east Forties. Slight or moderate, occasionally rough. Showers. Good.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error
Petr Špaček wrote: > > 2. Second problem is that it is uncelar if there is going to be a > consumer: Did *anyone* from stub resolvers said a word about this draft? > Is it useful as it is? I expect almost no-one can do anything with EDE without getaddrinfo() EAI_ return code extensions. Tony. -- f.anthony.n.finchhttp://dotat.at/ Plymouth: Variable 4 or less. Smooth or slight, occasionally moderate later in west. Mainly fair. Good.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] valid value range for SOA REFRESH/RETRY/EXPIRE
神明達哉 wrote: > > Anyway, my interpretation of the responses so far (or the lack of > thereof) is that no one knows (or cares about) the exact range (per > protocol standard) for these parameters. That's not the best result I > wished to see, but at least it looks like I didn't miss anything > obvious for others. I would be inclined to treat them like TTL values and follow section 8 of RFC 2181, but as Mark said, the signedness doesn't affect the behaviour since you'll be clamping the values between something like a few minutes and a few weeks. Tony. -- f.anthony.n.finchhttp://dotat.at/ Portland, Plymouth: Northeast 3 or 4, becoming variable 3 or less later. Smooth or slight, occasionally moderate at first in west Plymouth. Showers. Good.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-12.txt
Wes Hardaker wrote: > > It's this one: > >3.15. Extended DNS Error Code 14 - Not Ready D'oh! > One, the latest version talks about servers MAY put in more than one > EDE. Oh wow, that will be fun... Tony. -- f.anthony.n.finchhttp://dotat.at/ Biscay, Southeast Fitzroy: Southwesterly 5 or 6, veering northwesterly 3 to 5. Moderate at first in Biscay, otherwise rough or very rough. Occasional rain. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-12.txt
Viktor Dukhovni wrote: > > On Oct 2, 2019, at 8:01 AM, Tony Finch wrote: > > > > Is this not also covered by EDE 9 (DNSKEY missing) and EDE 10 (RRSIG > > missing)? > > No it is not. The indeterminate state happens when DS RRset lookups > servfail, for the zone or one of its ancestors, this could be a lookup > timeout or a validation issue. So not identical with DNSKEY missing. So EDE 22 or 23 then? You can't handwave "validation issue" here because the point of these error codes is to explain what kind of validation issue. > > [ I'm still not convinced "indeterminate" is a coherent validation state... > > ] > > It happens when glue NS records are available, but DS RRsets are not. That is "insecure". I think the definitions of the terms in RFC 4033 are a lot more clear than RFC 4035. By the 4033 definitions the distinction between insecure and indeterminate is whether you have a covering trust anchor or not, so nothing is indeterminate any more for normal validator configurations. Tony. -- f.anthony.n.finchhttp://dotat.at/ Dover, Wight: South 4 or 5, veering west 5 to 7, perhaps gale 8 later. Slight or moderate, becoming moderate or rough, occasionally very rough later in Wight. Fair then rain. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-12.txt
I have had another read through. In the intro, one of the example uses for EDE is a server returning errors because it has not finished starting up, but there is no EDE code for this case. Re. EDE 0 "other", is it supposed to cover the situation when there are multiple errors, e.g. different authoritative servers have different problems? Re. EDE 5 indeterminate, RFC 4035 says: Indeterminate: An RRset for which the resolver is not able to determine whether the RRset should be signed, as the resolver is not able to obtain the necessary DNSSEC RRs. This can occur when the security-aware resolver is not able to contact security-aware name servers for the relevant zones. Is this not also covered by EDE 9 (DNSKEY missing) and EDE 10 (RRSIG missing)? [ I'm still not convinced "indeterminate" is a coherent validation state... ] Re. EDE 11 no DNSKEY zone bit, why is there a special case for this and not for DNSKEY protocol not equal to 3? Are either of these errors that anyone has seen in the wild? (If so I would love to know how that came to pass!) Tony. -- f.anthony.n.finchhttp://dotat.at/ contribute to the process of peace and disarmament, the elimination of world poverty, and the collective safeguarding of democracy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-extended-error status
Wes Hardaker wrote: > > 2) One outstanding topic of discussion that I think we need to decide to > handle or table till a future document: how do we handle forwarding, > chained resolvers, and caching. Difficult. In general there will be multiple upstream servers, even in the simplest case of a stub talking to a recursive server talking directly to authoritative servers. So there can be an arbitrary combination of upstream errors, and they might not relate directly to the QNAME, (e.g. problems with a parent zone, problems chasing down nameserver addresses). Perhaps if the upstream problems are consistent with each other, the resolver can return a single extended error code to its client; otherwise fall back to a "multiple errors" catch-all? Tony. -- f.anthony.n.finchhttp://dotat.at/ Malin: East backing northeast 5 to 7. Moderate or rough. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs
Wes Hardaker wrote: > > + Response: Those three codes were supplied in a previous comment > round and they are supposed to indicate policies being applied from > different sources. Can you check the new text of them to see if > they are more understandable now? The filtering / blocking explanations are much more clear now, thanks! > 14.9.3 DONE 3.21. Extended DNS Error Code 20 - Lame > > > This needs to be split into two: server doesn't know about the zone > queried for (typically RCODE=REFUSED), and server knows about the zone > but it has expired (typically RCODE=SERVFAIL). > > Resolvers handling RD=0 queries typically answer from cache or would > answer REFUSED/Prohibited, I would have thought. > > + Response: I created an "Invalid Data" error code to handle this. > Does this work for you? Oh, funny, that sounds to me like an error from a primary server complaining about a malformed zone file. So that's a third kind of lameness! I like the 'not authoritative" explanation. Tony. -- f.anthony.n.finchhttp://dotat.at/ Hebrides, Bailey: Northeast backing north 5 or 6. Moderate occasionally rough. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-08.txt
Petr Špaček wrote: > > IMHO the most useful information is dichotomy: > > a) the problem is local (= call network admin/ISP/telco) > > b) the problem is remote (= call your bank because their internetbanking > broke and _do not your bother ISP_). I think that's helpful. There's an interesting case wrt blocking / censorship, e.g. "near block" => ISP is responsible; "far block" => required by force of law. Tony. -- f.anthony.n.finchhttp://dotat.at/ Portland, Plymouth, Biscay: West or southwest 5 to 7, occasionally gale 8 later except in Biscay. Moderate or rough, becoming rough or very rough, occasionally high later in northwest Plymouth. Rain or thundery showers. Good, occasionally poor.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs
Some questions about the intended meanings... 3.6. Extended DNS Error Code 5 - DNSSEC Indeterminate If I remember correctly, there isn't a consistent definition of what "indeterminate" means. Perhaps it's worth adding a reference to the intended definition. [ actually maybe all the codes could have citations to where the error cases are mentioned in existing specifications, perhaps with a comment that the citations are not intended to be exhausive ] 3.5. Extended DNS Error Code 4 - Forged Answer 3.16. Extended DNS Error Code 15 - Blocked 3.17. Extended DNS Error Code 16 - Censored 3.19. Extended DNS Error Code 18 - Filtered I don't understand the shades of meaning that these are supposed to distinguish. wrt "filtered", the description implies vaguely RPZ flavoured filtering, but it mentions a REFUSED RCODE which isn't what a sensible implementation would use for that purpose, so I am more confused. 3.18. Extended DNS Error Code 17 - Prohibited If I understand correctly, the four above are about the qname whereas this is about the client? The ordering is a bit confusing. 3.21. Extended DNS Error Code 20 - Lame This needs to be split into two: server doesn't know about the zone queried for (typically RCODE=REFUSED), and server knows about the zone but it has expired (typically RCODE=SERVFAIL). Resolvers handling RD=0 queries typically answer from cache or would answer REFUSED/Prohibited, I would have thought. Tony. -- f.anthony.n.finchhttp://dotat.at/ Hebrides, Bailey: West, backing south for a time, 4 to 6, increasing 7 to severe gale 9, occasionally storm 10 in Hebrides. Rough or very rough, becoming high or very high. Rain or showers. Good, becoming moderate or poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard
Viktor Dukhovni wrote: > > I am a bit puzzled by the lack of text that motivates treating TTLs > with the high bit set as positive? Why is this desirable, and why > in this draft? What is the connection between TTLs with the high > bit set and Serve Stale? If some resolver inadvertently returns > stale data whose TTL has expired, it might return a negative TTL, > and treating that as "0" seems safer than as 137 years (likely > then capped to 7 days). I guess this change is a result of trying to fill in the missing parts of what a TTL means. I don't think this change is necessary: the draft could be a bit less fussy without it. The draft says: [RFC2181] aimed to provide "the precise definition of the Time to Live", but in Section 8 was mostly concerned with the numeric range of values and the possibility that very large values should be capped. (It also has the curious suggestion that a value in the range 2147483648 to 4294967295 should be treated as zero.) Which implies to me that the authors didn't spot the TTL bug in RFC 1035 that RFC 2181 was fixing with the curious suggestion. RFC 1035 is inconsistent about the signedness of TTLs, so RFC 2181 fixed it by specifying that TTLs are to be treated as unsigned (as usual for DNS data) but must only use the range of positive signed 32 bit numbers. Quoting from RFC 1035 to point out the curious copy and paste bug: [ snip ] 3.2. RR definitions 3.2.1. Format All RRs have the same top level format shown below: [ snip ] TTL a 32 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted. [ snip ] 4.1.3. Resource record format The answer, authority, and additional sections all share the same format: a variable number of resource records, where the number of records is specified in the corresponding count field in the header. Each resource record has the following format: [ snip a second copy of the same info ] TTL a 32 bit unsigned integer that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded. [ snip ] Tony. -- f.anthony.n.finchhttp://dotat.at/ Rattray Head to Berwick upon Tweed: Southwesterly veering northwesterly later, 4 or 5, increasing 6 at times, becoming variable 3 or 4 for a time in south. Slight or moderate, occasionally smooth in south. Rain later, otherwise mainly fair. Good, occasionally poor later. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt
Paul Wouters wrote: > > I dislike Do53, because then we should really have Do53-over-TCP as DoT > and Do53-over-https as DoH. If we call it "DNS-over-TCP" than really > what we are doing is running (classic) DNS over TCP, and we shouldn't > midway the discussion rename "DNS" to "Do53". These abbreviations are about identifying the transport that is being used for the DNS messages. One problem with Do53 is that it isn't specific about the transport, because it covers both UDP and TCP. But it's a handy abbreviation for DNS over traditional transports. It doesn't identify DNS as a whole, just the framing of DNS messages in UDP and TCP. Tony. -- f.anthony.n.finchhttp://dotat.at/ a just distribution of the rewards of success ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt
Normen Kowalewski wrote: > > what do you use then for "traditional DNS over UDP/TCP” aka Do53 I like Do53. I also like DONUTS (DNS over normal unencrypted TCP streams) but that joke is a bit over-ripe. Tony. -- f.anthony.n.finchhttp://dotat.at/ Fitzroy, Sole: Southerly veering westerly 5 to 7, occasionally gale 8 at first in west Sole, decreasing 3 or 4 later. Rough or very rough. Thundery showers. Good, occasionally poor.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Obsoleting DLV
Samuel Weiler wrote: > > That does not include the argument in the below bullet, which I find unclear. > What does "name redirection" mean in this context? > >o Since the zones are related to private networks, it would make > more sense to make the internal network more secure to avoid name > redirection, rather than complicate the DNS protocol. I guess it's referring to active DNS modification attacks? Another reason not mentioned in the draft is resilience against loss of connectivity. If you have a local trust anchor you can validate local zones even when you can't reach the outside world. With normal DNSSEC validation everything is screwed if you can't obtain the chain of trust. Of course, the network should be secure and reliable in its lower layers, but I tend to think the DNS should be secure and reliable itself, even if the lower layers are a bit dodgy. Having thought about this a bit, I now prefer something like catalog zones as a way to distribute trust anchors. Tony. -- f.anthony.n.finchhttp://dotat.at/ Lundy, Fastnet: Variable 2 to 4 in east Lundy, otherwise southerly veering southwesterly 4 to 6. Slight or moderate in east Lundy, but elsewhere moderate or rough. Thundery showers. Moderate or good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt
Stephane Bortzmeyer wrote: > > Seen on a slide at IETF 105 : > > DoTH (to talk about DoH and DoT together, as in "DoTH use TLS to > protect DNS queries against snoopers"). > > A nice addition? :-) DoTH is the abbreviation I use for my documentation about encrypted DNS since August last year, https://www.dns.cam.ac.uk/servers/doth.html Tony. -- f.anthony.n.finchhttp://dotat.at/ Wight: Variable 2 to 4, becoming cyclonic 5 to 7 for a time. Smooth or slight becoming slight or moderate. Squally thundery showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] some 2015-era thoughts about RFC 7706 -bis
Paul Vixie wrote: > > first, all complexity comes at a cost. the new code and configuration needed > to support "mirror zones" will be a life long source of bugs and > vulnerabilities, because that's true of every new feature. the desired benefit > should be weighed against this cost. "by running one on the loopback" fails > this important test, mostly because it only applies to the root zone. Yes. I also agree with Geoff Huston's article from April that hyperlocal roots are not a compelling imrovement when we have DNSSEC negative answer synthesis, which applies to any NSEC zone, not just the root. https://www.potaroo.net/ispcol/2019-04/root.html > second, RDNS name servers who wanted to support this feature, which all must, > due to the competitive nature of the open source infrastructure community, > have to add features very much like authority DNS. Ironically, unbound has been growing more and more features for serving authoritative data. There are fairly compelling operational pressures that drive recursive servers to become more and more complicated, because they are a very powerful point of control. Tony. -- f.anthony.n.finchhttp://dotat.at/ Great Orme Head to the Mull of Galloway: South 3 to 5. Smooth or slight. Mainly fair. Moderate or good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Caching of negative zone (non-authoritative) responses
Michael J. Sheldon wrote: > > If a record is requested from an authoritative server, where the zone > does not exist, generally the response is REFUSED, but *this is not > cached* by the requesting server. This results in a nearly continuous > stream of retries, which continue to result in the same response. Our > authoritative servers see no less than 15%, and sometimes as much as 25% > of our worldwide traffic as these non-authoritative responses. Yuck :-( BIND's default lame-ttl is 10 minutes; I don't know if other resolvers have a similar feature. It might be better from your point of view if the lame-ttl matched the delegation TTL, but I bet that would be a bit frustrating for operators who set up a new delegation in the wrong order! Tony. -- f.anthony.n.finchhttp://dotat.at/ Dogger: Variable 2 to 4, becoming south 3 to 5. Slight. Rain. Good, becoming moderate or poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] proposal: Covert in-band zone data
Joe Abley wrote: > > There is hence an operational risk that data will leak (e.g. by > configuration changes, software downgrades that are pragmatic > necessities, side systems that publish zone data in ways other than the > DNS). > > By keeping data that is already exchanged over a (manual) out-of-band > channel separate, and not packaging them up with zone data, the existing > segregation of private vs. public is preserved and the task is simply to > automate a process that is currently manual. Yes. It might make sense to put secret keys in catalog zones. Tony. -- f.anthony.n.finchhttp://dotat.at/ Cromarty, Forth, Tyne: South 3 to 5, becoming variable 3 or less. Smooth or slight. Occasional rain, fog patches. Moderate, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ANAME loop detection
Jan Včelák wrote: > > 2. QTYPE=ANAME: According to the current version of the draft, server > answering to ANAME must include the ANAME and should include the > sibling records. Let's modify the behavior and say the server should > not (must not) include the sibling records. Then the server performing > ANAME sibling address resolution could first query for ANAME before > trying A or . We get the same loop detection mechanism as with > CNAMEs at the cost of an extra query per ANAME The main reason I thought it would be a good idea to include sibling address records in ANAME responses was so that we could get a one-shot address query as a side-effect. But I think we keep learning that it is a bad idea to load too much stuff onto ANAME, so I think it's a reasonable trade-off to ditch the addr query feature so that loop detection is easier. Tony. -- f.anthony.n.finchhttp://dotat.at/ Isle of Man: West or southwest 3 or 4, becoming variable 2 at times. Smooth or slight. Fair. Good.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ANAME in answer or additional section [issue #62]
Matthijs Mekking wrote: > The main argument for putting it in the additional section is that given > the experience with DNAME, putting the ANAME in the answer section there > is a risk of interop problems (because there is an unexpected record in > the answer section). I think ANAME will cause too many problems if it puts unexpected records in the answer section. Speaking as an ANAME proponent, the reason ANAME is such a hack is for compatibility with the installed base, and it will be annoying if it isn't actually compatible and we have to wait another 10+ years to be able to use it without worries. We (mostly Chris Thompson) deployed DNAME in the reverse DNS in 2010 (the DNAME specification was published in 1999) and we observed at least two annoying interoperability problems: * glibc chattering noisily in syslog (fixed only 2 years ago) https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b9b026c9c00db1a1b5b4a3caa28162655a04a882 * mail delivery failures - MTAs typically have their own DNS message handling code which is often super careful I expect that there will be several more interestingly problematic DNAME failures in the forward DNS. Tony. -- f.anthony.n.finchhttp://dotat.at/ Gibraltar Point to North Foreland: Variable, mainly southwesterly 3 to 5, occasionally 6 in south. Smooth or slight, occasionally moderate in south. Showers then fair. Good, occasionally moderate at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?
Matthew Pounsett wrote: > > I feel like this is creating an even bigger potential problem. What > happens when the owner of the ANAME target legitimately wants that > name to go away, but some other zone owner is leaving an ANAME in > place pointing to that now-nonexistent name? Continuing to serve the > sibling records indefinitely seems like serve-stale gone horribly > wrong. It's worth noting that Oracle's ANAME model does not couple the sibling addresses to the ANAME target addresses. As I understand it, they have additional "fallback" infrastructure (web servers and whatnot) which is used when the ANAME target isn't available. I'm not sure how this would work as a replacement for CNAME, when the request from the user comes without any information about how to set up a fallback server. Tony. -- f.anthony.n.finchhttp://dotat.at/ Biscay: Variable 3 or less, becoming southeast 3 or 4. Moderate, becoming slight. Fair. Moderate or good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ANAME discussion
Vladimír Čunát wrote: > > I can't even see a simple way of detecting this. At least in the > implementation suggested by Jan where you have an authoritative that > calls out to a resolver (which calls out to authoritatives...) You could prevent the loop from leading to a circular dependency, rather than detecting the loop, e.g. if the auth always answers from zone or cache which are updated asynchronously. Maybe the auth's resolver could chase the chain by making ANAME queries; when the auth replies it can reply from zone data and skip filling in the additional section if it doesn't have fresh address records. The auth can be more eager to make recursive queries when it gets A or queries. 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
