[DNSOP] draft agenda IETF 120 DNSOP WG published
All, We are pleased to announce that the draft agenda for the IETF 120 DNSOP WG sessions is now available. The sessions are scheduled as follows: - Monday, July 22, 2024, from 15:30-17:00 PDT (22:30-00:00 UTC) - Thursday, July 25, 2024, from 18:30-19:30 PDT (01:30-02:30 UTC, July 26, 2024) You can view the draft agenda on the datatracker at the follwing link: https://datatracker.ietf.org/doc/agenda-120-dnsop/. We have time for one or two additional presentations during Session 2 on Thursday. If you would like to discuss a draft or an idea with the DNSOP WG, please contact the chairs. Best, -- Suzanne, Tim and Benno ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Fwd: New Version Notification - draft-ietf-dnsop-domain-verification-techniques-05.txt
On Thu, 11 Jul 2024, Tim Wicinski wrote: The stanford.edu example is useful, only because they don't show up in those alexa top-1000(000) lists. Like I am sure many here have, I dumped the TXT records to the top 1000 and while the majority use the format "token=value", there are several that use the "token:value" format. I wonder if there should be some suggestions for "long enough token value" ? The token is supposed to encode N random bits, so pick a value of 1/(2^N) that you think is close enough to zero. For these purposes, it's hard to imagine a plausible scenario where someone is deliberately trying to spoof a token with wildcards, so a small N should be fine. Don't forget that last question, if it's a tagged name that is supposed to be unique and you get junk records, try to pick out the good ones or give up? My preference would be to give up on the theory that it is not our job to work around your broken software. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Fwd: New Version Notification - draft-ietf-dnsop-domain-verification-techniques-05.txt
On Thu, Jul 11, 2024 at 3:36 PM John R Levine wrote: > On Thu, 11 Jul 2024, Tim Wicinski wrote: > >> A) Should verification records have a tag at the front of the data to > >> identify the record type? There's plenty of prior art for this, e.g., > >> the 63 text records at stanford.edu. Or you might say that a > >> sufficiently long random token in the interesting part will prevent > >> false positives so there's no need. > > > > Are you referring to the "token=value" ? This gets discussed in the Token > > Metadata section, and perhaps the document is using the assumption of _ > > foo-challenge.example.com makes it more relevant? > > right, if the value is long enough there's little chance of some other > random text record from a wildcard matching it by mistake > Also "token" is more generic which perhaps is not that obvious? The stanford.edu example is useful, only because they don't show up in those alexa top-1000(000) lists. Like I am sure many here have, I dumped the TXT records to the top 1000 and while the majority use the format "token=value", there are several that use the "token:value" format. I wonder if there should be some suggestions for "long enough token value" ? tim > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Fwd: New Version Notification - draft-ietf-dnsop-domain-verification-techniques-05.txt
On Thu, 11 Jul 2024, Tim Wicinski wrote: A) Should verification records have a tag at the front of the data to identify the record type? There's plenty of prior art for this, e.g., the 63 text records at stanford.edu. Or you might say that a sufficiently long random token in the interesting part will prevent false positives so there's no need. Are you referring to the "token=value" ? This gets discussed in the Token Metadata section, and perhaps the document is using the assumption of _ foo-challenge.example.com makes it more relevant? right, if the value is long enough there's little chance of some other random text record from a wildcard matching it by mistake Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Fwd: New Version Notification - draft-ietf-dnsop-domain-verification-techniques-05.txt
Duane Thanks for these. I'm going to capture these for the authors (at least one is currently on holiday). On Tue, Jul 9, 2024 at 5:55 PM Wessels, Duane wrote: > I read through draft-ietf-dnsop-domain-verification-techniques-05 and have > a few minor comments / suggestions. > > > > > this may result in IP fragmentation, which often does not work > > While it’s true we have come to agree that fragmentation is bad for DNS, I > think “often does not work” overstates the situation. I’d say it works > more often than not and I don’t see draft-ietf-dnsop-avoid-fragmentation > making the case that fragmentation does not work. > > > > Depending on message size limits configured or being negotiated, it > > may alternatively cause the DNS server to "truncate" the UDP response > > and force the DNS client to re-try the query over TCP in order to get > > the full response. Not all networks properly transport DNS over TCP > > and some DNS software mistakenly believe TCP support is optional > > ([RFC9210]). > > I have mixed feelings about this. While perhaps factually true, I think > broken DNS-over-TCP shouldn’t be a reason for not lumping validation > records together. There are other valid reasons to avoid that practice and > networks with broken DNS-over-TCP shouldn’t be coddled. > > Most DNS-over-TCP does seem to work effectively, even with enterprise type resolvers (MS comes to mind). > > When multiple distinct services create domain Validation Records at > > the same domain name, > > services don’t create records, users/administrators do. Maybe reword as > “When multiple distinct services specify placing domain Validation Records > at the same …” > > good point. > The presence of a Validation Record with a predictable domain name > > (either as a TXT record for the exact domain name where control is > > being validated or with a well-known label) can allow attackers to > > enumerate utilized set of Application Service Providers. > > Not sure I buy this argument. Doesn’t the draft recommend using > predictable names anyway, just one per provider? > The discussion was "if we suggest predictable names, bad actors can search for _foo-challenge.example.com and find out if the domain uses such services, in an attempt to exploit." The authors didn't come to any decision. This may be an excellent bike shed for the working group. (I believe as a domain administrator that I would end up placing bogus TXT records in my domain, to throw off bad actors. "they claim to have docusign but we can't find a way in") > > > 1) A domain name related to the domain name being validated 2) A > > Validation Record, either directly in RDATA or as the target of a > > CNAME (or chain of CNAMEs) > > It’s not clear to me if this an “OR” list or an “AND” list? > > This I feel I'll answer badly, so I'll make a note for the authors. > because base64 relies mixed case > > "utilizes mixed case”? > yes > > Application owners SHOULD consult the IANA "Underscored and Globally > > Scoped DNS Node Names" registry [UNDERSCORE-REGISTRY] to confirm > > there are no collisions with existing entries. > > maybe this could be less passive as “consult … and avoid using underscore > labels that already exist in the registry”? > > I'm OK with this. I think the guidance is hoping folks prevent collisions. > either the RDATA or a domain name > > > The RECOMMENDED format for a Validation Record's domain name is > > > > > Here and in numerous other places I think “domain name” might be better as > “owner name”. i.e.: "the owner name of a validation record" > > "owner name" sounds a wee bit vague. But I understand what you're driving at. > > without having to hand over full DNS access > > what is DNS access? ;-) > "access to the owners domain records" > > by letting the Intermediary place the random token in their DNS > > in their zone? > "Intermediary place the random token into their own DNS zone" But yes. > APIs SHOULD be used to relay instructions. > > Not sure I follow this. An API to relay instructions? > I'm thinking this comes from reading all the ACME challenge documents. This needs either clarification or removal > > TTL Considerations > > If I were writing software to verify domain control, I probably wouldn’t > use a caching resolver. I’d just send queries to authoritative name > servers to avoid caching. The draft doesn’t seem to have any thoughts on > this one way or the other? > Should the draft have thoughts on this? I prefer authoritative servers but sometimes the tooling that queries these records are baked into current infrastructure. > > > > CNAME Records for Domain Control Validation > > I think the document could be more clear or explicit that a CNAME target > must exist. i.e., a random token in the owner name of a CNAME record is > not sufficient and such a CNAME whose target does not exist should be > treated as a failure, right? > Yes I believe so. > > > > Application Service Providers MAY incl
[DNSOP] Idea/suggestion on refs
One of the potential challenges for RFCs is references to works-in-progress or other less-than-stable items (URIs). Here is my thought: would updating those be something that could be handled by errata rather than doing a -bis? Brian Sent from my iPhone ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Fwd: New Version Notification - draft-ietf-dnsop-domain-verification-techniques-05.txt
I'm going to try to answer a few of these John, as acting Document Shepherd, herder of author kittens. On Tue, Jul 9, 2024 at 5:23 PM John Levine wrote: > It appears that Tim Wicinski said: > >This is one of those DNSOP documents that may not be relevant to those who > >implement DNS, or those who operate DNS infrastructure. It is relevant to > >Applications that use the DNS, and those who focus on what actually DNS > >records exist in zones. > > I took a look and it is indeed greatly improved. Here are some > implementation issues that may or may not be worth addressing: > > It says to put everything in a text record which is fine, but it > doesn't say anything about how to encode it. There are two competing > approaches. One says that the string boundaries in the record don't > matter, so combine all of the strings into one string. The other is to > treat each string as a token or expression, and the string boundaries > are the token or expression boundaries. The examples suggest the > former way, but it should say so. Alternatively, people checking > domain verification records need to say which way they're doing it. > This is valid, and we had some back and forth on how the encodings should be handled. It seems some of the motivations were left off. I'll leave this to the authors for confirmation. > Wildcards can cause some annoying problems, notably that a wildcard > will match any tagged name so queries for tagged names can get junk > answers. > > A) Should verification records have a tag at the front of the data to > identify the record type? There's plenty of prior art for this, e.g., > the 63 text records at stanford.edu. Or you might say that a > sufficiently long random token in the interesting part will prevent > false positives so there's no need. > Are you referring to the "token=value" ? This gets discussed in the Token Metadata section, and perhaps the document is using the assumption of _ foo-challenge.example.com makes it more relevant? > 2) If you put records at a tagged name that is supposed to be unique > and a query returns some junk records and some plausibly good records, > what do you do? Use what you can? Ignore it all because you probably > stepped on a wildcard? > Wildcards are brought up in Scope of Validation and Security Considerations, but more explicit text on handling is needed. > > Minor nit: why are the CNAME targets quoted? I've never seen a > quoted target name and when I look at RFC 1034 it doesn't look > like it's valid. > > This is totally my fault. I was going through and cleaning up the examples (making sure if all examples say "IN TXT" or had quotes around the TXT records), and in my focus on uniformity, I accidently did this. I'll file an issue to remove this. thanks tim R's, > John > ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Artart early review of draft-ietf-dnsop-domain-verification-techniques-05
Reviewer: Barry Leiba Review result: Ready This has a significantly expanded scope from the -01 version that I reviewed a while ago. I think it's solid, well written, and ready for last call. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values
Jim Reid writes: > IMO documenting the trade-offs in response sizes could be a better > option. ie if the response > X, it breaks foo; if it’s > Y it breaks > bar. I agree with the approach of limiting discussion of limits to recommendations. I am not a fan of enforcing lower limits in the wire format of what the protocol allows. I realize the draft is not currently phrased in terms of enforcing new limits; I'm just staking my ground. Also, this draft uses BCP14 boilerplate but only a few instances of capitalized BCP14 terms; I see two SHOULDs and one MAY. (Perhaps I miscounted.) Presumably it needs more RECOMMENDEDs. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values
> On 10. 7. 2024, at 15:36, Yorgos Thessalonikefs wrote: > > In general having limits in an RFC that people can point to goes a long way > than developers trying to argue with users; for example on what a sensible > length of a CNAME chain is. I agree with this rationale, but I would rather frame any document more like “if you are doing this things might not work” rather than saying “these are hard limits”. In any case, any document like this is doomed to fail unless you can get the DNS Silos to sign it with their own blood, because any rational argument will be shot down with “but it works with …”. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values
On Thu, Jul 11, 2024 at 09:39:04AM +0200, Philip Homburg wrote: > >Operations may be better served by a minimum expected level than a > >maximum. > > This is a matter of wording. > > Yes, it is possible to specify a minimum level that is expected from, for > example, a recursive resolver. > > However this is likely to become a maximum that a zone owner can rely on > to work on the internet. My concern is this too. The DNS works today. In several implementations, limits were added or decreased in recent months/years due to CVEs (and there will be more limits shortly). I don't know if there has been any study of what the impact of these changes was. In the case of our implementation with customers who have config knobs to change these limits, we haven't had any significant number of reports of breakage (the product is widely used at large-scale). I feel that prescribing limits will make DNS inflexible for use-cases that we in our current generation have not imagined of. The fact that DNS today is malleable is because RFC 1034/35 were very open-ended and not rigid. Mukund > > However I can understand that for some people a minimum may sound > more comfortable. So maybe a next version of the draft can use that kind > of wording. > > ___ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values
>Operations may be better served by a minimum expected level than a >maximum. This is a matter of wording. Yes, it is possible to specify a minimum level that is expected from, for example, a recursive resolver. However this is likely to become a maximum that a zone owner can rely on to work on the internet. However I can understand that for some people a minimum may sound more comfortable. So maybe a next version of the draft can use that kind of wording. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values
Hi Philip On Thu, Jul 11, 2024 at 08:50:57AM +0200, Philip Homburg wrote: > > Even RFC 1034 says "Bound the amount of work", but explicitly > > prescribed numbers in an RFC may end up being arbitrary. > > > > When there is a difference between something working well and not > > working well, it may either be due to too much work (too much NS > > lookup indirection for example) or implementation inefficiency (use > > of data structures that are inefficient, or resource limits on that > > particular platform such as amount of memory available). > > That is a different issue. The issue is that recursive resolvers implement > arbitrary default limits to avoid issues. Any zone that exceeds those > limits is in trouble. > > At any moment a popular resolver can release a new version of the software > with lower limits. Breaking zones that worked before. > > That is a very unstable situation that in can be avoided mostly by only > increasing limits. > > But when new attacks suggest that limits need to be lowered, this becomes > a real risk. > > > So a limit on section counts may be appropriate, but the limit that > > an implementation is able to perform well with is best decided by > > its implementors. There may be implementations that may perform > > well with thousands of RRs on commodity hardware and support very > large RRsets. > > How that help a zone owner? A zone that only works with some resolvers? Operations may be better served by a minimum expected level than a maximum. Mukund ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values
On 7/10/24 20:08, Ben Schwartz wrote: Why? Do we really care if a resolver limits the size of RRsets to 32 KB? Yes. Unnecessary limits restrict our flexibility even if mainstream use cases don’t exist today. Absolutely agree. Peter ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
