Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

[John Levine]

It appears that Peter Thomassen   said:
>The _signal label generically indicates that ns2.foobar.fi likes to signal 
>something about nohats.ca. Its presence is needed to allow separating the 
>object from the source without ambiguity.
>
>We could change _signal to something else, but not to _dnssec-bootstrap as 
>that's not generic. Suggestions are welcome.

They're all DNSSEC related so how about _dnssec-signal ?

>I'd like to add some considerations:
>
>- The spec has quite a few production implementations (see Section 8), and 
>changing them would come with significant costs.
>
>- I don't think the _signal label is in use for the Signal messenger. Even in 
>case it's used in the future, a collision (in terms of prefix labels + rdtype) 
>seems unlikely.

It's not but _signal is an awfully generic term, and I do not want to
count on people inventing sufficiently distinct second level _label
names to keep unrelated uses separate.

When we were collecting names for the _label registry there were a
few places with overlapping names like the URI RRTYPE, and it's
a mess.  Let's not do it again.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

[John Levine]

It appears that Dave Lawrence   said:
>Stephane Bortzmeyer writes:
>> > One current implementation does not differentiate DO=0 vs 1 and gives the
>> > same NODATA answer for both cases.
>> 
>> Yes. I see no practical problem with that but, from a philosophical
>> point of view, it disturbs me. Naive clients may make wrong
>> conclusions from the NODATA answer. 
>
>Very much so, and not just naive programmatic clients but also
>non-naive real-life human clients.  I myself have been misled by
>noerror/nodata where nxdomain would have been correct.  It's
>frustrating.
>
>nxdomain is usefully distinct and auth servers really ought to be
>strongly encouraged to return it where applicable.

We have an entire RFC 8020 about the difference and why it's important.

>From my point of view, anything that doesn't keep that distinction is 
>seriously broken.

R's,
John



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Do we need new draft that recommends number limits ?

[John Levine]

It appears that Paul Vixie   said:
>-=-=-=-=-=-
><
>I think it would be better to compile them all into one draft.>>

I agree a draft describing the places where DNS evaluators
should set limits would be a good idea.

I am considerably less enthusastic about specific limits, since
the use of the DNS has evolved a lot and some things that may
bave seemed excessive back in the day are now routine.

The obvious example is CNAME chains. In 1034/1035 the only use
contemplated for CNAME was temporary forwarding when a host name
changed, and for that use, chained CNAMEs made no sense. Now they
delegate authority to different points of control in many different
ways. For applications like CDNs, you need two or three link CNAME
chains and nobody appears to find that a problem.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Nothing more useful to say About key tags

[John Levine]

It appears that Philip Homburg   said:
>>Not at all. This would be an incompatible change that breaks existing
>>working DNS configurations, for at most a trivial simplification in
>>load limiting code many years from now, even assuming people were to
>>implement it.
>
>Opinions difference how much this change will help.
>
>The point I wanted to make is that this change does not lead to issues at
>level of DNSSEC standard protocols.

But that point is completely wrong.  What you propose is a breaking change.  It
is incompatible with existing DNS standards.  So, no.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Nothing more useful to say About key tags

[John Levine]

It appears that Philip Homburg   said:
>What I mean is that if we take all of the standards track DNSSEC RFCs and we
>add a new RFC that says something to the effect:
>1) A signer MUST NOT sign a DS or DNSKEY RRset if the set has duplicate key
>   tags.
>2) An authoritative DNS server MUST not serve a set of RRSIG records that 
>   corresponds to a single RRset where the collection of RRSIG records has a
>   duplicate key tag.
>
>then as far as I can tell, there is no conflict with currently published
>standards track DNSSEC RFCs. 

Not at all. This would be an incompatible change that breaks existing
working DNS configurations, for at most a trivial simplification in
load limiting code many years from now, even assuming people were to
implement it.

No.  Just plain no.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] About key tags

[John Levine]

It appears that Shumon Huque   said:
>Yes, I agree. (Banning keytag collisions, if we are proposing that, is a
>protocol change.)
>
>Not also that DNSKEY set "coherency" is not really the issue. Even for a
>single signer they may be temporarily incoherent across nameservers because
>of normal change propagation delay. Multi-signer operations (for steady
>state or for a transitional state needed for DNS operator changes) can
>extend that period substantially. Collision avoidance is about the key
>generation process and the set of entities involved.

ISC has this nice page about how they dealt with keytrap:

https://www.isc.org/blogs/2024-bind-security-release/

About halfway down is a section "DNS scalability: the good, the bad,
and the ugly" which lists all the different ways a buggy or malicious
server might return stuff that is expensive to process, and then
points out that it is not a bug that the spec does not put hard limits
on any of them. As the Internet has evolved, people have come up with
clever ways to use the DNS, and the lack of hard limits enables it.
The obvious example is CNAME which was originally intended as a
temporary forwarding address but has evolved into all sorts of
mutlti-step cross-domain use without which CDNs would be impossible.

So of course we will describe all the ways we know to detect
and deal with scalability problems, but the solution (so far at
least) has never been to invent a new hard limit.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] About key tags and sensible limits

[John Levine]

It appears that Mark Andrews   said:
>It’s not the complexity of the validator we are worried about.  The number of 
>crypto verifications per second is really low on all
>hardware.  Being able to stop validating on the first failure rather than 
>having to continue because the attacker has constructed a
>colliding key tag rrset is beneficial to getting good put trough in the 
>presence of a DoS attack.

Why do you have to try to validate everything rather than do some
sensible number and stop? When I look at RFC 4035 sec 5.3.3 I don't
see any MUSTs.

I could set up a 100 link CNAME chain that would resolve if you
followed the whole thing, but every cache will stop long before that.
Why is this different?

R's,
John

PS: I wouldn't be opposed to something like RFC 9276 that offered some
advice for things to limit in practical DNS resolution, but that's not
a protocol change, more like a BCP.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] About key tags

[John Levine]

It appears that Mark Andrews   said:
>The current “fixes” still leave validators more vulnerable to cpu exhaustion 
>attacks than eliminating colliding key tags in the signer does. This is a 
>protocol bug that leads to
>cpu exhaustion.  We, the IETF, have a duty to fix this at the protocol level. 

I'm having trouble understanding how this is fundamentally different
from CNAME loops, or NS sets with silly numbers of NS or A records.

The kind of load is different but in each case the client needs to
limit the amount of work it's willing to do. We can forbid it in the
protocol but unless you have better contacts at the Protocol Police
than I do, people will do it anyway.

R's,
John

PS: Try looking up 1.2.3.4.contacts.abuse.net.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] About key tags

[John Levine]

It appears that Peter Thomassen   said:
>
>
>On 2/16/24 17:19, Jim Reid wrote:
>It rather seems like inviting instability, then telling the signer "well, you 
>knew...! Or should have, at least."
>
>I don't see in what way that's better than what we have with the current 
>fixes, which successfully address the problem and (AFAICS) don't need to be 
>touched again.

While I should have been doing something else, I scanned all of the
gTLD zone files with more than a million names looking for keytag
collsions.  I also looked at .SE and .NU because the zone files
are available and .NU has a lot of signed delegations.  The total
number of domains was about 200 million although most of them are not
signed.

The total number of domains where I found duplicate tags was 105. Of
those, all but 20 were KSK and ZSK with the same tag which should be
harmless. The total number where there were more than two tags with
the same ID was ZERO.

So while I understand why BIND and Unbound did the stuff they did, in
practice if you return SERVFAIL when you see three keys with the same
ID, you will be fine and nobody will notice. Counting RRSIGs is harder
but given the low number of keys, I expect a similarly low limit on
signatures would be equally effective.

This really is a tempest in a teapot.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] on private use TLDS: .interNAL -> .LAN

[John Levine]

It appears that Joe Abley   said:
>Hey,
>
>Op 27 feb 2024 om 12:08 heeft Toerless Eckert  het volgende 
>geschreven:
>
>>   I would like to see a BCP RFC on the use of the "internal" TLD,
>>   and ICANN should not finalize availability of the TLD unless that RFC 
>> exists.
>
>Surely what ICANN is preparing to do is make a decision that an "internal" TLD 
>should never be available. I don't know what there is to be
>finalised beyond that decision, or what availability means in that context. 
>Can you explain?
>
>I am also not sure why an IETF document describing an ICANN decision about the 
>namespace would help. If you are suggesting that this is not
>ICANN's decision to make on its own, then I think you are mistaken. 

Sounds like he's confusing .INTERNAL which is for DNS names that are resolved 
locally
and the .ALT non-DNS TLD in RFC 9476.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] work limits - RFC 4035 section 5.3.3

[John Levine]

It appears that Petr � pa� ek  said:
>TL;DR is:
>
>RFC 4035 section 5.3.3. Checking the Signature
>has a MUST loop doing crypto operations over product of #DNSKEY * #RRSIG 
>set (for matching key tags), and this can be damn expensive.
>
>Of course we should have listened to RFC 1034 page 35 "limit amount of 
>work" advice ...

There are innumerable ways that a DNS server can return answers that
ask the client to do an unreasonable amount of work. This one is
unusual in that the work all happens at once while processing the
response, but so what, make sure you limit the number of times through
each processing loop.

At contacts.abuse.net I have a little DNS server that lets you look up
contact info, e.g. example.com.contacts.abuse.net will give you the
info for example.com in TXT records. A few client systems hammer on it
with odd queries like one that seemed to be looking up every name in
the .AT TLD.

So they get a special response, a referral with 10 NS records, each
with a name they can look up to get 25 pseudo-random A or  records.
I figured this would provoke complaints, so I could tell them to cut
it out.  But it hasn't, so that's evidently something they've
limited so it doesn't matter.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOPComments on draft-dnsop-deleg-00.txt - section 1

[John Levine]

It appears that Ralf Weber   said:
>I agree that future extensions will require code changes, but having a
>record type that is extensible from the start might make it easier to
>deploy new parameters then it is to do a full RRTYPE, at least that is
>the hope.

If the RRTYPE is extensible, how do two DNS servers negotiate which
extensions they can handle?  So far we have been fairly careful to
add things in a way that either you do it or you don't and even that
has problems we all have seen.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS: .interNAL -> .LAN

[John Levine]

According to Paul Wouters  :
>
>> On Jan 27, 2024, at 16:42, Paul Marks  wrote:
>> 
>>  pick .lan
>> instead?  It seems that a lot of people are already using this abbreviation 
>> on their internal
>networks, which happen to be local in
>> area.
>
>LAN implies local area network. So an organization with multiple locations 
>would have a LAN at each
>location, but the .LAN would be their collection of LANs? I think that would 
>lead to confusion.

It's also the name of a group of airlines in South America.  I was surprised 
none of them applied
for a vanity TLD.

The name .INTERNAL is fine.  Let's argue about something else.

R's,
John


-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DELEG-00 draft submitted

[John Levine]

According to Roy Arends  :
>Hi,
>
>I’ve been made aware that the name of the submitted draft is not in line 
>with the guidelines:
> ...
>
>I’ll wait for instructions from WG chairs regarding the name, until then, 
>happy reading!

When you resubmit, could you please submit XML so it can create easier to read 
HTML and PDF?

I see the source ie a .md file so it's just a different option to kramdown.

R's,
John
-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Followup Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

[John Levine]

It appears that Tim Wicinski   said:
>For WGLC, we need positive support and constructive comments; lack of
>objection is not enough.
>So if you think this draft should be published as an RFC, please say so.

I think we should publish it, but I also think we should publish the
NOTIFY draft at the same time so we don't have yet another thing that
requires DNS scanning.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Resolver behaviour in the presence of unrequested answer records

[John Levine]

It appears that Bellebaum, Thomas  said:
>> Without being able to cite chapter and verse of a relevant RFC, I
>> would say that the client (stub resolver?) ought to toss RRsets
>> which are unrelated to the resolution of the original queried-for
>> name.
>
>That is what we would have expected, and what seems to be implemented
>in many popular DNS resolvers. Some of them do not even look at
>unrelated records and simply follow the CNAME chain to the requested
>RRs.
>
>We figured there must either have been universal silent agreement on
>this in the WG or this must have come up at some point (possibly while
>working on DNSSEC?).

That's cache poisoning.  Search for "Eugene Kashpureff" to learn all
about it.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Dealing with some open Errata:

[John Levine]

It appears that Paul Wouters   said:
>> Section 4.1.2. says:
>>   | URI    | _dccp | [RFC7566] |

>I think this might have been part of a list used to "reserve" the names
>of (transport) protocols, so that constructs like _25._quic.example.com
>could be constructed where the _name denotes the protocol and not the
>name of something. I think dccp got added to this list because it is
>references as a "transport protocol" in RFC4340 and the author wanted
>to make sure transport protocol names were not accidentally squatted
>by newly invented things with a clashing name/acronym.

I think I'm the one who added it and that was definitely the idea. You
should be able to use SRV or URI with any transport protocol so in
view of the modest set of transport protocols in use, we might as well
reserve their names. Dunno where that RFC number came from, though.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-bellis-dnsext-multi-qtypes-08.txt

[John Levine]

It appears that Paul Wouters   said:
>On Fri, 17 Nov 2023, Ray Bellis wrote:
>> [ bitmaps ]
>I think it would be unwise to make assumptions on how people will use
>this feature. They might want to ask for many more records along with
>A/ records. If we change a core DNS feature, it should not designed
>for a specific DNSSD use case of HTTPS.

I can think of a lot of applications where you might want two or three
RRTYPEs, e.g. MX+A+ for mail lookups, A+TXT for dnsbls, but I'm
coming up blank for more than that. If someone could suggest a
plausible use for six or seven or more, the bitmap might seem useful.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

[John Levine]

It appears that Peter Thomassen   said:
>Dear DNSOP,
>
>(This is mainly for those who did not attend today's DNSOP session in Prague.)
>
>The chairs announced today that the below WGLC meant to say that some 
>reactions in support of this draft are needed for the document to move
>forward. (In contrast to only asking for objections.)

I think the document is ready EXCEPT that we really need to reconcile
it and the notify draft. If there's going to be notifications, we
should say so now rather than hoping people notice there's some
slightly later RFC that updates this one.

In the absense of notifications, scanning would be rather expensive
since the registry would need to probe all the signalling domains for
every unsigned registrant. In some cases they might have a shortcut
like being able to AXFR signalling zones but in general you can't
count on it.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QNAME minimization is bad

[John Levine]

It appears that Paul Wouters   said:
>On Fri, 10 Nov 2023, John R Levine wrote:
>
>> Subject: [DNSOP] QNAME minimization is bad
>> 
>> Well, not always bad but sometimes.
>
>A bit misleading subject :P

It seems to have done the trick.

>> I'd like to write a draft that updates RFC 9156 by describing situations 
>> like 
>> this that caches could recognize and avoid useless churn, added to section 
>> 2.3 which already suggests special casing underscored labels.
>
>Couldn't the RBL's add an underscore in their base zone name to trigger
>the special casing in 9156? That would not require a new RFC and
>perhaps might not require code updates?

DNSBLs have been around a lot longer than QNAME minimization. They
work(ed) fine without minimization and I don't think it is reasonable
to expect every mail system in the world to change their configuration
to work around our performance bug.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] NOTIFY: How to locate the target

[John Levine]

It appears that Paul Vixie   said:
>-=-=-=-=-=-
>None of the above. Do what RFC 2136 does to send updates to the primary 
>authority, or do what RFC 1996
>does to send notifications to all listed authorities. Any new signaling is 
>effectively a way to go out
>of band. The system is complete as it is. 

Without manual configuration, how is the child supposed to know where to find
the stealth parent to notify?

R's,
John

>On Nov 8, 2023 12:06, Peter Thomassen  wrote:
>
>Dear DNSOP, 
>
>As laid out at the DNSOP session on Tuesday, 
>draft-ietf-dnsop-generalized-notify (and also
>draft-johani-dnsop-delegation-mgmt-via-ddns) require a method for locating the 
>parent-side endpoint
>(target) where the child DNS operator can send a NOTIFY for DS update (or 
>other kind of signal). 
>
>Locating the target via a DNS query needs a predictable qname and type. The 
>feeling from the room was
>that for various reasons, a new rrtype with SVCB semantics should be used. 
>
>As for the qname, the authors would like to gather some feedback from the list 
>regarding the preferred
>approach. The below uses the domain "child.se" for illustration: 
>
>Alternative #1(a): Look up record at se. (delegating parent's apex) 
>- Simple 
>- Clogs the apex with more records 
>- Likely does not cover all use cases (such as per-registrar target, when they 
>want to process the NOTIFY) 
>
>Alternative #1(b): Look up record at _notify.se. (some underscore label below 
>parent) 
>- Slightly more complex than above 
>- Avoids clogging the apex, at the expense of some namespace pollution 
>- Covers same use cases 
>
>Alternative #2: Look up record at child._notify.se. (or other magic label) 
>- Allows parent to publish per-child targets (e.g. the registrar's endpoint) 
>* Needs maintenance or synthesis 
>- Magic label could be considered namespace pollution 
>- Unneeded complexity if parent is not a registry (e.g. a university) 
>
>Alternative #3: Try #2, and on failure fall back to #1(a) or #1(b) 
>- Combines simplicity and flexibility, but conceptually most complex 
>- Might cause two DNS queries 
>
>Please weigh in on what you think is the best approach. 
>
>Thanks, 
>Johan, John, Peter 
>
>-- 
>https://desec.io/ 
>
>___ 
>DNSOP mailing list 
>DNSOP@ietf.org 
>https://www.ietf.org/mailman/listinfo/dnsop 
>
>-=-=-=-=-=-
>[Alternative: text/html]
>-=-=-=-=-=-


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Automated delegation management via DDNS

[John Levine]

It appears that Johan Stenstam   said:
>Ok, let me rephrase: As a synchronisation mechanism based on a signed DNS 
>UPDATE message that carries both the data to be
>modified and the proof that the change request originated with the owner (the 
>child) and has not been modified in transit…
>it works equally well with or without DNSSEC.

That is true, but it also means that the two ends have to arrange out of band 
to share the
signing key, which is the usual scale problem that makes this stuff fail.

I think that extending NOTIFY for the small set of cases in the draft is fine,
particularly if we also add a case to notify for the DNS bootstrap.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] draft-thomassen-dnsop-generalized-dns-notify and draft-ietf-dnsop-dnssec-bootstrapping

[John Levine]

I was looking at these two drafts. The first one says that scanning
for CDS updates is bad, so use NOTIFY(CDS) rather than scanning. The
second one says to scan for DS bootstrap.  I am experiencing cognitive 
dissonance.

I suggest adjusting the bootstrap draft saying to send NOTIFY(DS) to
the parent of a delegated name to tell it to do the bootstrap rather
than scanning. The issues in section 3 about why scanning is bad and
in section 4 about where to send the notification are exactly the same
as what's there now.

I suppose you could overload NOTIFY(CDS) and the parent does one or
the other depending on whether the zone already is signed but it seems
to me that the operations are different so the notification might as
well be different too.

Bonus update: if we do this, in the bootstrap draft take out section
4.3 on triggers and instead say to use notify.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-generalized-dns-notify

[John Levine]

It appears that Suzanne Woolf   said:
>Please also indicate if you are willing to contribute text, review, etc. It�s 
>particularly helpful if you can comment on
>whether you would implement or use this feature.

I have my doubts about secs 4.1 and 5.1 that try to publish the target of 
notifies, but they're not fatal.

Yes, I'll review, etc.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

[John Levine]

It appears that Paul Wouters   said:
>On Jul 17, 2023, at 22:50, Paul Vixie  
>wrote:
>> 
>> 
>> 
>>> Agreed, but that horse had already left the barn when we published the 
>>> first SPF RFC 4408.
>> RFC 4408 was folly. TXT in a subdomain (RFC 5507 s3.2) would suit domain 
>> verification well (wildcards aren't a
>factor) and would in no way be precluded by the SPF design.
>
>The IETF did make a mistake there for sure.

I wouldn't disagree, but you can barely see the spots in the dirt
where the barn was before the horse left. Viz the pile of junk at the
apex of any domain of any organization of any size. If performance or
token collisions were a practical problem, surely someone would have
noticed by now.

In any event, per Shumon's message there are plenty of administrative
reasons to encourage people to put their tokens at _name without
reference to how much stuff there is or isn't at the apex.

R's,
John

PS: Let's visit the Ivy League!

$ host -t txt harvard.edu
harvard.edu descriptive text 
"globalsign-domain-verification=9ff12eafbeebb02a0f2b0383aef9d1fa"
harvard.edu descriptive text 
"globalsign-domain-verification=5A1F4E0081852ECB9015E837384121AD"
harvard.edu descriptive text "fastly-domain-delgation-vdnblsdg768nm-21052021"
harvard.edu descriptive text "v=spf1 redirect=_spf.harvard.edu"
harvard.edu descriptive text 
"ciscocidomainverification=41ce9827e3fbbca9ce75d5dbb5a6bc7b089dc4e239c1b56ba828216d1214480"
harvard.edu descriptive text "MS=ms35192554"
harvard.edu descriptive text 
"globalsign-domain-verification=87677a19ae97bfbeec25ff1510a80420"
harvard.edu descriptive text 
"google-site-verification=xqg8LPF_v_QMEIST789q8xhRDqUEX4_8lQjAvV6YykY"
harvard.edu descriptive text 
"google-site-verification=pWvLuNePLYxAbafZw2a95vnBhvcj12DzM9NulT9ujSY"
harvard.edu descriptive text 
"xIGeuA0e5B1BOjTE4IBO806ziFX9G1m2dVJ8zO7CMkmKwZ6MEkMXC0P7n5SRCGOdS9jbceH/7gKYgD4h9FBGKA=="
harvard.edu descriptive text 
"heroku-domain-verification=1qfmzz9vp3kexf4fr5zuliwvpieih2ffz4gexo7tlh4"
harvard.edu descriptive text 
"jAykGnWytyLeBseMa8x2/MBve6/yQqana4yrAc1ROoei7uZHUkM2FU0Xx4qI/rm+kOGdImZdoq0fdodgLEw1dg=="
harvard.edu descriptive text 
"pardot962443=9098884472c5cb29a2e20700b41411cb4aa5ebcf340360e71b2cd8464d8864b6"
harvard.edu descriptive text 
"globalsign-domain-verification=dcc2e5d0d67efc32044ae679c7cf19e6"
harvard.edu descriptive text 
"pardot679353=f93ea3588d69483bf48dbf587511f51d43ddadaae52b8bac6856c8428559a06d"
harvard.edu descriptive text 
"airtable-verification=a92cef30671587a4f6deb7951c1c3f1a"
harvard.edu descriptive text "status-page-domain-verification=p83gt91wpxms"
harvard.edu descriptive text "status-page-domain-verification=b4j4g69th3vv"
harvard.edu descriptive text 
"google-site-verification=DzhZyP8pu0M1-RFghfTcSN-9poidboYRNdfn2Rf2hCQ"
harvard.edu descriptive text 
"pardot378242=7001579db574e062735763ba81b54da111abc31facf16bbfa653ab6b8a770988"
harvard.edu descriptive text 
"pardot_378242_*=8b485d5cd9114869cff8f307da5fa9287434ebec11621d88c07ce97a7fee06e0"
harvard.edu descriptive text 
"globalsign-domain-verification=1C94E0FFAAE95796F597427644D90C03"
harvard.edu descriptive text 
"smartsheet-site-validation=jfLh_IkQNJXuKKpTn7RydwiiaAOLy4CR"
harvard.edu descriptive text 
"pardot679353=3cc5e124c5020a1e160f01981f45be33a467a1c802711e0e5654184ef56d18c9"
harvard.edu descriptive text 
"google-site-verification=lY-T8NneGQX1RGXeaoBJjSmT_lx3dLRKDq1xY44ZI5w"
harvard.edu descriptive text 
"adobe-idp-site-verification=66e813947c764d98330002232f383a68df8ad609065abb9482f3805dd2a1902c"
harvard.edu descriptive text 
"atlassian-domain-verification=Z8oUd5brL6/RGUMCkxs4U0P/RyhpiNJEIVx9HXJLr3uqEQ1eDmTnj1eq1ObCgY1i"
harvard.edu descriptive text 
"Peh2GHoW8uiAzwS9tTZKlGBn9cMq6Y+XUFtrqmLtqFh1WvloPkzGczPsZcSdDfin4hZ7QiL9J7SM8yr7Yyzi8w=="

$ host -t txt yale.edu
yale.edu descriptive text 
"airtable-verification=5faa4d445f2f11d5a2e0d2dff8c4d287"
yale.edu descriptive text 
"amazonses:9Ya8iDYeN700mkvk/yE/JXHlH/zQjYAA6+XyWlnms+E="
yale.edu descriptive text 
"atlassian-domain-verification=d6trxstBXPKZ-Fn96brt+2GuIbtk29HYhBAdLyXwH1GGOd5OqEaoeX1j7Iako4Y8"
yale.edu descriptive text 
"d365mktkey=Nf1xniLZCW9LJtMAKbxJ4QluH18K7RKSYYw5ndrkxlox"
yale.edu descriptive text 
"d365mktkey=qXRmZD4AqCPHhxJWI7EnhD5InEkYOsYQ6eidVZHnCyAx"
yale.edu descriptive text "docusign=a560f5e1-1b15-42e8-9630-f9f375c0d326"
yale.edu descriptive text "docusign=e8f08e07-8b40-4ae4-a8cf-7ce972d4b382"
yale.edu descriptive text "dropbox-domain-verification=y270qicvbi7s"
yale.edu descriptive text "e2ma-verification=tmfcb"
yale.edu descriptive text 
"facebook-domain-verification=4b2v2cdl4pnhet6qnrtzuof73xy5ic"
yale.edu descriptive text 
"google-site-verification=fUwYVutFF-kUCTqnDZg7s4lWZSUTOO2k2zHogw_1qYw"
yale.edu descriptive text 
"google-site-verification=wAcIxfMZtLARxIU3MA82C9ywf-MODgjwuP2JdcSvs3E"
yale.edu descriptive text 
"google-site-verification=wLNdYe7PcFN1GTfpDeWAT-aPFTWpa_fMn7ZWDw07cuc"
yale.edu descriptive text 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

[John Levine]

It appears that Paul Wouters   said:
>On Jul 17, 2023, at 14:12, John R Levine  wrote:
>> 
>> 
>> In view of the wide use of DNSSEC and DoT and DoH, I think the argument that 
>> triggering TCP is bad stopped being persuasive a while ago. 
>(Don't we hope people sign the DNS responses with the tokens?)
>
>I’m sure there are still plenty of tools crafting dns packets or using 
>simplistic tools that are not able to do TCP or DNSSEC. 

I'm sure there used to be, but in 2023?  Really?  An example or two would be 
intersting.

>> The only somewhat plausible argument I see against stuffing the apex is that 
>> if people are sloppy, they might invent tokens that could be
>confused with each other. ...
>
>It’s literally what happened to me in the first week of my current $dayjob. I 
>found 5 tokens that no one knew what they were, whom they were
>for and whether or not they were still needed.

Um, no. I believe you don't know what they were, but that doesn't mean
anyone or anything thought that a token for A was a token for B.

Anyway, we agree that adding a bunch of extra stuff to SPF results is a bad 
idea and
that's sufficient motivation to tell people to use _names for their tokens.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

[John Levine]

It appears that Florian Obser   said:
>I gave this a once-over.
>3.  Common Pitfalls
>> If the size of the response is large enough that it does not fit into
>> a single DNS UDP packet (UDP being the most common DNS transport
>> today), this may result in fragmentation
>
>That's not correct. If the response does not fit into a single DNS UDP
>packet, it's not a valid response and can't be send.
>
>New: If the size of the response is large enough that it does not fit
>into a single IP packet this may result in fragmentation

That's not right either. If it doesn't fit in a UDP packet, the
response will be truncated and the client will retry over TCP. If the
UDP packet exceeds PMTU, the packet will be fragmented in transit but
there's no simple way to know that at the application level. There's a
reason EDNS0 let the client suggest a packet size limit, and people
have been tuning their use of it since 1999.

The entire discussion of response size seems like a throwback to the
1990s and I would remove it. These days if your DNS doesn't handle
TCP, you already have worse problems, like DNSSEC doesn't work.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [v6ops] WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01

[John Levine]

It appears that Vasilenko Eduard   said:
>-=-=-=-=-=-
>1. 464XLAT is indeed an alternative, but a bad one: it means that the client 
>should have a local IPv4 subnet.
>The DNS resolver should prepare the packet in IPv4 format, then fetch it to 
>the CLAT engine where it would be translated to IPv6.

I'm with Mark here. If you want to talk to IPv4 devices, it makes a
lot more sense for your local router or device to give you an RFC1918
network which then lets you use the real far end IPv4 addresses and
signed DNS records, than to require every bit of addresss management
and DNSSEC code to do special hacks to try and peer through the other side
of the NAT.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-dulaunoy-dnsop-passive-dns-cof

[John Levine]

It appears that Ben Schwartz   said:
>-=-=-=-=-=-
>As noted in RFC 8499, "Passive DNS" raises some significant privacy concerns.  
>This is true even when client IP addresses are omitted. 
>For example, the proposed format includes timestamps.  An adversary who can 
>record encrypted DNS traffic and can acquire corresponding
>Passive DNS logs could "join" the two datasets to break the protection offered 
>by encrypted DNS.
>
>I hope the working group will weigh the privacy considerations carefully when 
>deciding how to proceed.

I take your point, but I hope we agree that omitting timestamps from the spec
won't make them go away.  It's fine to describe the security issues, but let's
not make the NAT mistake and imagine that not documenting it will make people
stop using it.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)

[John Levine]

It appears that Peter Thomassen   said:
>Hi John,
>
>On 6/20/23 20:27, John Levine wrote:
>> It appears that Peter Thomassen   said:
>Do you mean that there needs to be a way for registrars to tell a registry 
>what their NOTIFY listening endpoint is?
>
>EPP, to my knowledge, is for management of domain registrations, while that 
>endpoint is a global property ...

Good point.  They'd still need to invent something to manage the endpoints, and 
there's the painful ICANN process
to allow putting anything new in the TLD zone file.

>>> How would a random DNS operator know the registrar of their customer zones? 
>>> How would they learn when it changes?
>> 
>> They'd ask the customer "who's your registrar" when they set up the
>> zone.
>
>Ah, but then that's not what we're trying to do, which is improving CDS 
>processing. So far, it's done via CDS scanning which does not
>involve the registrant but is automatic (that's already in the title of RFC 
>7344).
>
>Unfortunately, the timing of the scanning queries does not align well with 
>when a CDS change is actually happening. 

This is precisely the same situation we have always had with zone
updates and AXFR. If you don't care how fast your secondaries sync,
you can just wait for them to scan for SOA changes. If you do care, you
figure out where to send the NOTIFY messages.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)

[John Levine]

It appears that Peter Thomassen   said:
>My take is that the parent should create a _signal subdomain (preferably as a 
>delegation). The per-child target can be queried by prepending, e.g.
>
>   _notify.example._signal.parent.  IN NOTIFY  CDS scheme port 
> scanner.registrar.example.
>
>This way, the parent can announce the registrar's NOTIFY endpoint. This can be 
>synthesized dynamically, no need to maintain a large zone.
>As _signal can be delegated, only one (rather normal) NS RRset is required in 
>the parent, and the magic can be done on a different
>nameserver.

While I can see how that might work in principle, I find it hard to
imagine registries and registrars making it work. At the least it'd
need new EPP stuff to tell the registry what signal records to add or
delete.

>> I guess if the targets are fairly static, then putting it in the 
>> configuration rather than sticking it in the DNS will be good enough.
>
>How would a random DNS operator know the registrar of their customer zones? 
>How would they learn when it changes?

They'd ask the customer "who's your registrar" when they set up the
zone. This still misses the hard part about how the notify knows where
to expect the notifies from. I suppose by default it could be the
delegated NS, but in interestingly large setups, that's not likely to
be adequate.

If the customer changes registrars, they have to tell the DNS operator
but that's easier than the current hacks to try and move DS records
from one registrar to another.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)

[John Levine]

It appears that Matthijs Mekking   said:
>Hi,
>
>I like this draft because of it tackles the issues of wasteful CDS 
>polling and it uses NOTIFY, a mechanism that is well known, already 
>exists in implementations, and actually feels like a good fit (as 
>opposed to overloading).

Agreed.

>A note on where to send CDS and CSYNC notifications. I sort of 
>understand why the NOTIFY record includes a RRtype field, but will 
>parental entities really have a different target for receiving notifies 
>for CDS and CSYNC?

I've talked to Peter at some length.  The problem is that you will often have
different targets for different children of the same parent, i.e., registrars
rather than registries, and I don't see any good way of putting per-child
info in the parent, particularly a large parent like .ORG or .COM.

The existing NOTIFY for AXFR is perfectly usable without a mechanical
way to say where to send the notifications, so my proposal is to
continue not to have one. All of the existing AXFR NOTIFY receivers I
know have ACLs to only accept notifications from relevant primary
servers, often hidden ones not visible in the DNS, so even if the
proposal in 5.1 didn't have scaling problems, it only addresses half
the problem. So take it out.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY

[John Levine]

It appears that Mark Elkins   said:
>> There are registries doing CDS scanning now, and registrars testing
>> it. I agree that the flow back to the registrar if the registry does
>> it is ugly so registrar is better where possible. We'll probably end
>> up with both since some registrars aren't up to it.
>
>My thoughts on this as in how to decide who does what, is...
>
>in EPP, there is a section that I've coded to look like...

We're talking about this at the ICANN meeting this week, and I
hope we will find something that the gTLDs will be willing to do.

Do keep in mind that there are domain boundaries other than ones at
TLD/registrant boundaries.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY

[John Levine]

It appears that Mark Elkins   said:
>> What has changed is the start of some Registrars taking on the role of 
>> "agent" for Registrants doing DNSSEC. ...
>> So, the NOTIFY target could be such an agent (Registrar) who then 
>> forwards the appropriate update to the TLD via EPP.
>> I.e. the target would not be the TLD itself (directly).

That was the thought. There's a certain amount of hand waving about
how you find the NOTIFY target but no more than there is now for SOA
NOTIFY.

>This is certainly the approach I'd like to see. As a Registrar, about 
>40% of the Domains I've registered on behalf of Registrants are under my 
>DNS management and thus there is no need for either Polling or 
>Notifies. I'd also rather be in the path of any Updates by Registrants 
>that outsource their DNS.

For the large fraction of domains managed by the registrar, this stuff
doesn't matter unless a registrant delegates subdomains and wants to
sign those.

There are registries doing CDS scanning now, and registrars testing
it. I agree that the flow back to the registrar if the registry does
it is ugly so registrar is better where possible. We'll probably end
up with both since some registrars aren't up to it.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[John Levine]

It appears that Mark Andrews   said:
>> Oh, I completely agree.  My point was just that even in the root which is 
>> small and you
>> would hope would change slowly, it's still a challenge to track what's lame.
>
>It’s not a challenge to track what is lame.  It’s dead simple.  You just have 
>to look.  Getting
>it addressed is the challenge.

Yeah, that's a better way to put it. But the main point still stands,
that it would be a signficant operational change to insist that all
delegated NS be active when delegated, and even moreso to insist that
they continue to be active.

Back in the 1990s when you registered names by email, NetSol checked
that your NS were active before accepting them, but that was back when
it was normal for the back and forth for registering a name to take a
week.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[John Levine]

It appears that Kim Davies   said:
>With that said, I think the root zone is probably not an instructive
>use case for the broader question. Unlike typical zones, at the root it
>can be said every delegation is to critical Internet infrastructure and
>therefore the calculus around process complexity and efficiency would be
>weighted differently.

Oh, I completely agree.  My point was just that even in the root which is small 
and you
would hope would change slowly, it's still a challenge to track what's lame.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[John Levine]

It appears that Dr Eberhard W Lisse   said:
>The IANA Function Operator does so for all ccTLDs (which would imply all TLDs).

Indeed, but some of them are lame anyway.  Here's today's report:

FAIL ne. bow.rain.fr. 194.51.3.49 All nameservers failed to answer the query 
ne. IN SOA: Server 194.51.3.49 UDP port 53 answered REFUSED
FAIL ne. ns-ne.afrinic.net. 2001:43f8:120:0:0:0:0:45 All nameservers failed to 
answer the query ne. IN SOA: Server 2001:43f8:120:0:0:0:0:45 UDP port 53 
answered REFUSED
FAIL pg. ns1.tiare.net.pg. 202.165.192.23 All nameservers failed to answer the 
query pg. IN SOA: Server 202.165.192.23 UDP port 53 answered SERVFAIL
FAIL ss. b.ns.tznic.or.tz. 196.216.162.70 All nameservers failed to answer the 
query ss. IN SOA: Server 196.216.162.70 UDP port 53 answered SERVFAIL
FAIL tg. ns1.admin.net. 198.73.186.1 All nameservers failed to answer the query 
tg. IN SOA: Server 198.73.186.1 UDP port 53 answered SERVFAIL
FAIL ye. ns1.yemen.net.ye. 65.162.184.33 All nameservers failed to answer the 
query ye. IN SOA: Server 65.162.184.33 UDP port 53 answered SERVFAIL
FAIL ye. ns2.yemen.net.ye. 65.162.184.34 All nameservers failed to answer the 
query ye. IN SOA: Server 65.162.184.34 UDP port 53 answered SERVFAIL

There are 96 more that timed out but I can't tell whether they really aren't 
there or it's a temporary network issue.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[John Levine]

It appears that Joe Abley   said:
>Pre-delegation checks add friction to the domain registration process. They 
>further complicate the commuications between different actors in the 
>commercial graph
>(registrars, registries, resellers, DNS operators, hosting companies) and 
>introduce delay and manual intervention into what might otherwise be a fairly 
>automated
>or at least automatable process. ...

Thirty years ago, when you did domain registrations by e-mail, the
registry which was then called Network Solutions did indeed check that
your name servers were active before delegating the domain. It was not
an accident that they stopped doing so, and it seems vanishingly
unlikely that any gTLD registry would do so now, regardless of
what people here might think.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion

[John Levine]

It appears that Suzanne Woolf   said:
>Colleagues,
>
>
>This email begins a Working Group Last Call for 
>draft-ietf-dnsop-zoneversion-02 
>(https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/).
>
>If you've reviewed this document and think it's ready for publication, please 
>let us and the WG know, by responding on-list to this message. We particularly 
>need to hear
>from implementers and operators whether this EDNS option is implementable and 
>useful.
>
>If you don't think it's ready, and have specific concerns or suggestions, 
>please let us know about those too.

Since it's a year old, has anyone implemented it beyond the one server listed 
in the draft?

I think it's an interesting idea but I also don't want to spend time on it if 
it's just going to be filed and forgotten.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] can someone forward this to benno?

[John Levine]

It appears that Paul Vixie   said:
>-=-=-=-=-=-
>
>i don't know why it was rejected as spam but his sysadmin might.
>
It's because redbarn.org has a p=reject DMARC policy.

To summarize a lot of prior discussion, "don't do that".

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: Compact Denial of Existence in DNSSEC

[John Levine]

It appears that Tim Wicinski   said:
>-=-=-=-=-=-
>
>Happy Monday (UTC) All,
>
>The chairs heard some strong support to adopt and work on this.
>
>This starts a Call for Adoption for draft-huque-dnsop-compact-lies
>
>The authors did do some updates in the draft around the "lies" moniker.
>Once adopted perhaps someone can suggest a better draft name.
>
>The draft is available here:
>https://datatracker.ietf.org/doc/draft-huque-dnsop-compact-lies/
>
>Please review this draft to see if you think it is suitable for adoption
>by DNSOP, and send any comments to the list, clearly stating your view.

I think we should adopt it but I am quite unhappy that in its current
form, there is no way for clients to tell when a server is using this
hack, and it silently turns NXDOMAIN into NODATA for existing clients
that haven't added code to look for NXNAME.

I would be OK with an EDNS0 "tell me lies" flag from the client.  It would
only affect NXDOMAIN resposnes, which could use the NXNAME hack if the flag
is set, otherwise the server has to return a real NXDOMAIN.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Updated: Compact Denial of Existence

[John Levine]

Now it sounds like NXDOMAIN turns into SERVFAIL. When I have a decent keyboard 
I'll suggest a way this might not break unmodified downstream clients. Sent 
from my Galaxy
 Original message From: Shumon Huque  Date: 
3/15/23  09:18  (GMT-05:00) To: John Levine  Cc: 
dnsop@ietf.org Subject: Re: [DNSOP] Updated: Compact Denial of Existence Only 
for Compact Answers, otherwise downstream validators may treat the response as 
unvalidatable because the rcode doesn't match the DNSSEC proof. So, I actually 
see this is unbreaking things.I think it's worth taking a step back though and 
asking a larger question: if we are restoring the NXDOMAIN signal with the 
NXNAME pseudo type in the NSEC record of NODATA responses, why do we also need 
to restore NXDOMAIN into the RCODE field?The answer to that I think is that a 
number of folks have argued to me that there are tons of security, analytics, 
and traffic characterization tools in existence today that look at the RCODE 
field for this purpose, and they are presently already broken because of this. 
We could ask them to modify their implementations to infer NXDOMAIN from the 
NXNAME pseudo-type, but who knows how long that will take (if ever).Shumon.On 
Wed, Mar 15, 2023 at 10:04 AM John Levine  wrote:Wait, so if 
my cache does this and I change nothing, it silently turns NXDOMAIN into 
NOERROR? That is badly broken.Sent from my Galaxy Original message 
From: Shumon Huque  Date: 3/15/23  07:48  (GMT-05:00) 
To: Ralf Weber  Cc: John R Levine , 
dnsop@ietf.org, pe...@desec.io Subject: Re: [DNSOP] Updated: Compact Denial of 
Existence Precisely,  but it can still work if the signal is used in a hop by 
hop fashion.So, if a resolver sends EDNS CompactAnswersOK signal to an 
authority server, which returns a NODATA+NXNAME proof + RCODE=3 response, then 
the resolver would have to intelligently manage that answer in its cache. To 
downstream DO=1 queriers that also set CompactAnswersOK, it could return that 
answer as is. To those that don't, it would have to reset the RCODE to NOERROR. 
This imposes more complexity on the resolver implementation of course, but I 
don't see any reason why it wouldn't work - and it would be optional anyway. 
Clients that want to see the NXDOMAIN signal in the RCODE might push their 
resolver service to implement it.Shumon.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Updated: Compact Denial of Existence

[John Levine]

Wait, so if my cache does this and I change nothing, it silently turns NXDOMAIN 
into NOERROR? That is badly broken.Sent from my Galaxy
 Original message From: Shumon Huque  Date: 
3/15/23  07:48  (GMT-05:00) To: Ralf Weber  Cc: John R Levine 
, dnsop@ietf.org, pe...@desec.io Subject: Re: [DNSOP] Updated: 
Compact Denial of Existence Precisely,  but it can still work if the signal is 
used in a hop by hop fashion.So, if a resolver sends EDNS CompactAnswersOK 
signal to an authority server, which returns a NODATA+NXNAME proof + RCODE=3 
response, then the resolver would have to intelligently manage that answer in 
its cache. To downstream DO=1 queriers that also set CompactAnswersOK, it could 
return that answer as is. To those that don't, it would have to reset the RCODE 
to NOERROR. This imposes more complexity on the resolver implementation of 
course, but I don't see any reason why it wouldn't work - and it would be 
optional anyway. Clients that want to see the NXDOMAIN signal in the RCODE 
might push their resolver service to implement it.Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Updated: Compact Denial of Existence

[John Levine]

It appears that Peter Thomassen   said:
>So I take it that when the EDNS signal is there, compact DoE responses get an 
>NXDOMAIN code.
>
>In case the EDNS flag is not set, does the nameserver return (a) the compact 
>proof (with sentinel in
>the type map) is sent, but with a NOERROR code, or (b) a classical proof (no 
>sentinel), but with an
>NXDOMAIN code?

It would return a RFC 4470 white lie, which does the same thing but is
larger since it needs two NSEC and two RRSIG records, one for the name
and one to show there's no wildcard.

I wouldn't try to get any more clever. Just use an EDNS0 code in the
query to say compact results are OK. I'd like to use the same code to
say this result is really NXDOMAIN, but those aren't signed, so I
think we do need to assign a metatype to go in the signed NSEC.

R's,
John



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The ALT Special Use Top Level Domain) to Proposed Standard

[John Levine]

It appears that Mark Nottingham   said:
>This seems fine. 
>
>I do wonder whether 'alt' is appropriate -- 'alternative' begs the question of 
>'alternative to what?' and the
>answer is a technical detail that most Internet users are blissfully unaware 
>of. It seems to me that it'd be
>better to choose something meaningful to users.
>
>That said, I struggle to suggest anything specific, and we have plenty of 
>examples of seemingly-relative names
>still working in practice -- e.g., 'New York.'  

The original impeteus was the alt.* usenet hierarcy.

This draft has been bouncing around since 2014 and I don't ever recall
anyone suggesting a name that worked beter than "alt". I think we
believe that it doesn't mean something grossly offensive in any
language we know.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Updated: Compact Denial of Existence

[John Levine]

It appears that Peter Thomassen   said:
>It seems that this perspective is generally shared, as nobody seems to have a 
>fundamental problem with changing the semantics
>of NODATA and essentially abandoning NXDOMAIN (for "do" queries). 

The reason nobody's arguing is that we resolved that issue seven years ago in 
RFC 8020.

R's,
John


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Updated: Compact Denial of Existence

[John Levine]

It appears that Peter Thomassen   said:
>> It will require more process work (potentially blocking) to revise other 
>> documents too.
>
>I checked before proposing it, and couldn't find anything that would need 
>revision. RFC 1035 calls that type experimental, no
>NULL RRs allowed in zone file, and content opaque (if used on the wire). To 
>me, that actually looks like a rather ideal set of
>pre-conditions.

RFC 6895 says:

RRTYPE zero is used as a special indicator for the
SIG(0) RR [RFC2931] [RFC4034] and in other
circumstances and must never be allocated for
ordinary use.

I suppose we can have a meta-discussion about whether this is an ordinary use, 
but I would prefer not to.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Updated: Compact Denial of Existence

[John Levine]

It appears that Shumon Huque   said:
>2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0 ...
>> If I didn't get the math wrong, it would also save 11 bytes in the type
>> bitmap (compared to using the lowest available meta type code, 128),
>> slightly reducing the chance of packet size issues e.g. when double-signing
>> etc.
>>
>
>I'm a bit allergic to re-using an RR type already designated for another
>purpose.

It seems like a poor economy.  If you really are worried about making the
bitmap smaller, I suppose there's unused type 54.  Anyone who's using DNSSEC
is already prepared for large responses so I wouldn't worry about it.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Updated: Compact Denial of Existence

[John Levine]

It appears that Peter Thomassen   said:
>I suspect it is intentional, because there seems little value in jumping 
>through the NSEC3 extra hoops like hashing and
>dealing with NSEC3PARAM when you don't get any of the benefit NSEC3 was 
>designed for. (Compact NSEC answers prevent zone
>enumeration just as well, if not better.)

The introduction does mention NSEC3.  

It seems worth mentioning that if you can do compact answers, NSEC3 has little 
(no?) benefit.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for "Domain Verification Techniques using DNS"

[John Levine]

It appears that Brian Dickson   said:
>DC templates generally are of the key/value pair structure, with the
>"value" typically being specific to the customer, such as a validation
>string.

Oh, OK, there's a concrete reason to use fixed names and put the token
in the body.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for "Domain Verification Techniques using DNS"

[John Levine]

It appears that Paul Wouters   said:
>But also, the pain is not felt at the people who dictate how to use
>their DNS validation scheme. It is with the DNS administrators finding
>a bunch of unrecognisable DNS records and not knowing what the hell
>they are for and whether they can or should be deleted. Or those admins
>that now see their APEX going back to TCP (yes dig txt cnn.com gets TC
>and falls back to TCP)

I think I just said that was a problem. But other than the advice to
put in an expiration date, and indirectly the advice not to put the
record at the domain apex, I don't see anything to fix that.

An expiration date could help for the one-off ACME stuff, but not for
the long term analytics which you can only really tell by asking the
other end if they're still looking at your stuff. So like I said it
would be good if you had a way to tell who the other end is.

It occurs to me that's a reason to use a fixed tag and add it to the
attrleaf registry. People can look it up to see what it is, and if you
have a way to see if it's still in use, perhaps a web page where you
can put in the random token and it says yes or no.


R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for "Domain Verification Techniques using DNS"

[John Levine]

It appears that Paul Wouters   said:
>> _a1b2c3.example.com IN ... "whatever"
>> _crudco.example.com IN ... "a1b2c3"
>
>Adding cryptogrpahically strong/long strings in the prefix seems
>unwieldly and prone to problems - especially if the user has to put
>these in via a webgui of mediocre quality. 

That makes no sense.  Why is it harder to copy a string to the name field
in a cruddy web GUI than to the data field?  It's copy and paste either way.

>Also it makes manual
>checking harder (eg to use the dig command). 

Same question, it's still copy and paste.

But most importantly, you
>already need a good prefix to identify the vendor and service 

No you don't. If you need a prefix to keep your 26 character randomly
generated tag from colliding with my 26 character randomly generated
tag, at least one of us needs a new random number generator.  If you want
to identify the vendor and service, that should be evident from the target
of the CNAME.

>and mucking up random strings there just seems the wrong thing to recommend
>as BCP.

It doesn't seem wrong to me.  I would hope a BCP would be based on something
more than "this seems ugly to me."

>> If you use a fixed prefix, _crudco in this case, you should register it
>> in the RFC8552 attrleaf registry.
>
>Since we are recommending these are easilly recognised to vendor and
>service, these would be different for each vendoer. Sure, we can add
>another prefix in between and put that in the attrleaf registry, but
>that doesn't add any real value.

No, that's not what I said. Each vendor should register its prefix
with attrleaf, not an extra noise word. It's not like it's hard to
register or there is a shortage of ASCII strings.

>> I realize that RFC1034 says
>> not to chain CNAMEs, but we all know that people chain CNAMEs and it
>> works, e.g. www.microsoft.com goes through three CNAMEs and it works
>> fine.
>
>I was not allowed this line or argumentation with you when talking
>about the LHS of an email address :) 

There is so much wrong in that statement I don't know where to start.

>People make mistakes with CNAMEs, let's not recommend CNAMEs so chances
>that people get affected my mistakes is reduced.

I have bad news.  People make mistakes with TXT records too.

In any event, this doesn't look like a BCP, it looks to me like
someone's personal preferences, not well supported by much else. I
would not publish it in anything like its current form.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-01.txt

[John Levine]

It appears that Shivan Kaul Sahib   said:
>-=-=-=-=-=-
>
>Hi folks, we (finally) published a new version of the domain verification
>techniques draft, now as intended-BCP. We've had some feedback from
>providers but would love for folks to review, especially people who would
>actually use it.

While I think it would be good to publish some best practices in this area,
this draft still seems scattered and makes some assertions that seem to me
to be somewhere between unsupported and mistaken.

I think we agree that the goal is there are two parties, call them
owner and verifier, and the verifier gives the owner a random token
that the owner puts in its DNS to show it owns the domain.  There are
a bunch of different aspects that one can look at independently.

One is where the token goes, in the name or contents of the owner's
record. I think we agree that putting the token at the owner's host
name is a bad idea, but either of these can work, with a1b2c3 being
the random token:

_a1b2c3.example.com IN ... "whatever"
_crudco.example.com IN ... "a1b2c3"

If you use a fixed prefix, _crudco in this case, you should register it
in the RFC8552 attrleaf registry.

Another is what record type to use. I find the arguments against CNAME
unpersuasive, basically saying that if you do something dumb, it won't
work, which is true, but it's always true. I realize that RFC1034 says
not to chain CNAMEs, but we all know that people chain CNAMEs and it
works, e.g. www.microsoft.com goes through three CNAMEs and it works
fine. If you use a _name in the attrleaf registry or a _random prefix
I would think the changes of a CNAME colliding with something else are
low, and a verifier presumably controls its own DNS and can keep CNAME
chains short.

So any of these could work:

_a1b2c3.example.com IN TXT "crudco"
_a1b2c3.example.com IN CNAME verify.crudco.wtf.
_crudco.example.com IN TXT "a1b2c3"
_crudco.example.com IN CNAME _a1b2c3.crudco.wtf.

As you sort of note in one of the appendices, you can have different
tokens in the name and the content if for some reason that is useful.

For the length of time the token is valid, there seem to be only two:
five minutes for a one-off verification like for ACME, or forever for
someone who is doing continuing analysis of something in your domain,
typically web analytics. While I can see aesthetic reasons to get rid
of expired one-off tokens, I don't see the point of putting an
expiration time in them, nor any particular harm in leaving them there
if they are at _name and not the main host name. You might also say
something about TTLs, e.g., not to have a 12 hour TTL for a token you
plan to remove in a few minutes.

There are some other minor points. You say to generate 128 random
bits, but then to hash them to 256 which I don't understand. (As RFC
4086 sec 6.2 notes, strong random bits often are already hash output.)
If 128 bits is enough, use 128 bits, if you need 256, generate 256.
Either way I'd do base32 rather than base64 encoding to make the
result more robust against helpful software that does you a favor by
case folding.

Overall, I'd lay out the options, and point out the advantages or
disadvantages of each rather than just saying "do this" without a
strong basis not to do it the other ways that work fine in practice.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: Structured Data for Filtered DNS

[John Levine]

It appears that Tim Wicinski   said:
>Please also indicate if you are willing to contribute text, review, etc.

I think it's worth adopting. 

My main concern is that it appears to assume that everyone in the
world can read English error messages, a problem it shares with RFC
8914. I can think of various ways to fix it, ranging from just
document the issue (for things like SOHO routers which already have a
way to configure the language for messages), fake it with geolocation
and pretend Belgium doesn't exist, or have an optional EDNS0 parameter
going the other way to say what languages you prefer.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-homburg-dnsop-codcp-00.txt

[John Levine]

It appears that Paul Wouters   said:
>On Tue, 10 Jan 2023, Philip Homburg wrote:
>
>[speaking as individual]
>
>>However, such a setup leaves the application with no control over
>>which transport the proxy uses.
>
>Why should the application have control over this? If you want to give
>control to the application, what should they control?

I'm with Paul here. If you don't like the way my resolver works, use
another one.

Experience also tells us that if you give users knobs like this, they
will use them even when (especially when) they have no idea what they
are doing.  "Someone said DoH pointing to this site in Russia is
super secure!"

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Private-use underscored DNS node name

[John Levine]

It appears that Eric Orth   said:
>-=-=-=-=-=-
>
>Am I interpreting the idea correctly that the goal here is to be able to
>create names that are only usable as alias targets?
>
>If so, interesting idea, but I'm not sure such a mechanism could actually
>be created and widely implemented.  I don't think there's enough motivation
>for all the relevant implementors to add code to block a previously-allowed
>name for non-alias use or to allow a previously-disallowed name just for
>alias use, ...

I have my doubts about whether this is really a problem that is worth
solving, since it's not very hard to invent alias hostnames that are
unlikely to collide.  You could for example prefix "service8000alias." to the
aliased name.

But if you want to do it, since the alias is a hostname, using
underscores would be a bad idea since several decades of software know
that hostnames can only be LDH. As part of IDNA we reserved all
hostnames of the form LL--stuff where LL is letters.  The only LL
currently in use is XN, for IDN A-labels.  I suppose you could use
AL--stuff labels for hostnames that are supposed to be aliases.  There
may be software that rejects LL-- names but I expect it's a lot less
than stuff that rejects underscore names.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on glue definition

[John Levine]

It appears that Ben Schwartz   said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>I agree; this is about utility, not necessity.  For example,  records
>are almost never "necessary" in glue, but they are useful, so they are glue.

Uh, what?  For the kazillion peoeple on V6 only mobile networks, the 
records are useful and the A records are a poor substitute.

I thought we had already agreed why, if you're going to send glue, you need
to send all of it and if you can't you set the TC bit.

(Ignoring the question of whether you consider cousin domain records
to be glue, which I do not.)

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] root crud, Possible alt-tld last call?

[John Levine]

It appears that Paul Hoffman   said:
>It is completely clear that, seven years later, many resolvers don't follow 
>that SHOULD NOT rule. In fact, at at least one root server,
>.onion queries appear more often than many gTLDs and ccTLDs.
>
>The question is thus, is the value of adding that special rule for every TLD 
>in the RFC 6761 registry worth the benefit? Given the
>example of onion, is such a benefit even noticeable, and if so to whom?

Vendors of DNS software who want to sell maintenance plans? I agree
that for many reasons telling people to add special cases to resolvers
isn't a good use of our or their time.

I also think more than ever that the details of the way that the root
servers provide NXDOMAIN to names that aren't in the root is an issue
for RZERC, not for dnsop.  It really doesn't matter whether the name
is foo.alt, foo.belkin, or foo.snerdlebarp.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] no regitry for you, Possible alt-tld last call?

[John Levine]

It appears that Eliot Lear   said:
>As a matter of practicality, a registry surely will be form.  It is 
>simply a matter of whether the IANA will host it.  If the IANA does not 
>host it, then by shifting it elsewhere this group is actually weakening 
>the IANA function, and that would be sad.

But trying to turn IANA and .alt into a junior version of ICANN would
be much worse than sad. Anyone who has spent any time at all anywhere
near ICANN will assure you that anything that looks even a little bit
like a place where party A can exclude party B from using name C will
attract a whole lot of attention from people you do not want to waste
time with.

I agree that nature abhors a vacuum, but for this particular vacuum,
I would be delighted for the suckage to happen elsewhere.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] protocol switches, was Possible alt-tld last call?

[John Levine]

It appears that Wes Hardaker   said:
>The probably *right* solution is to fix all the documents specifying
>implementation with respect to naming that assumes the DNS is the only
>system (URLs) [1], and all the APIs that make use of it (getaddrinfo).
>The list of RFCs to update to allow namespace selection is far from short.

I can think of at least three places where I've seen DNS protocol switches:

- turning a name into an IP address like getaddrinfo()

- turning a name into a set of RRs, like when you stick local stuff into
your DNS cache config

- turning a name into a socket, like with .onion

These are not mutually exclusive and there may be others. I'm not sure
whether this is an IETF topic or an IRTF topic, but I do think it is
long overdue for attention.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Proposal for Namespaced Service Names

[John Levine]

It appears that Jeremy Saklad   said:
>As an example, take a look at the Wikipedia page on SRV records: 
>.
> Of the
>19 examples of usage, at least 7 use service names that are not in IANA’s 
>registry. One, Matrix, even squats on an unrelated service that IS registered 
>with IANA.

It's a reasonable concern, but if people aren't willing to make the
very modest effort to register a service name with IANA, just filling
out a form on their web site, it seems unlikely that they would be
willing to do anything other than continus to squat.

I'd suggest instead registering names you know about, or enouraging people
using them to do so.  For "matrix" it looks like the current registration
is abaondned, so it might be possible to arrange to replace that with one
that is in active use.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [off-topic even more than non-IETF work] was Re: [Ext] name folding, was draft-ietf-dnsop-alt-tld-17

[John Levine]

It appears that Paul Wouters   said:
>On Wed, 24 Aug 2022, John Levine wrote:
>
>> Many people believe that but it's not entirely true.
>>
>> While most mail systems treat upper and lower case in local parts the same,
>> I have occasionally seen setups where you can send mail to sek...@example.com
>> and other capitalizations bounce.
>
>In my 30 years of SMTP email I have never run into this. "The expectation
>of the many, outweigh the expectation of the one" :)

If you don't spend much time writing or maintaining mail software,
it's not surprising that you wouldn't run into edge cases. You
wouldn't believe some of the strange stuff that Ned Freed described in
actual running systems at large companies that ran his mail software.

To look at it another way, in all the time I've been using the DNS
I've never run into an OPENPGPKEY record or turned on
edns-tcp-keepalive, but I have no objection to other people using
them.

>> Hence I would tell people that if they make their names case sensitive
>> they are likely to be sorry, but I wouldn't try to enforce anything.
>
>That sounds like a draft that could contain a SHOULD NOT or even a MUST
>NOT. Already better than the current status quo of an IETF requirement
>being completely obsoleted by real world deployments of billions of mail
>boxes.

After further consideration, I think we should stay completely out of
the business of offering advice on how to write things that look
like the DNS but are not the DNS. We have plenty of work already on
the thing that actually is the DNS.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] name folding, was draft-ietf-dnsop-alt-tld-17

[John Levine]

It appears that Paul Wouters   said:
>On Aug 24, 2022, at 11:27, Schanzenbach, Martin  
>wrote:
>> 
>> GNS, as in the protocol, does *not* consider "Example.gns.Alt" and 
>> "Example.gns.alt" to be the same name.
>
>FYI, on many mobile phones, words at the start are automatically capitalized, 
>so you are going to experience many user problems if
>your protocol sticks with this assumption. Punting this to the application to 
>fix up or punting it to the OS to configure
>duplicates with case differences is going to fragment how well gns works on 
>various OSes or applications. As Security AD, if this
>was an IETF protocol I would put up a blocking DISCUSS to address before 
>allowing the document to proceed.

So would I, but I think the goal here is to give people plenty of
rope. We hope what they build doesn't end up strangling themselves,
but there is deliberately no review of what people do with .alt.

>A well known mistake in this area from within the IETF is that the SMTP 
>protocol considers the LHS of an email address case
>sensitive, so paul@ and Paul@ are considered two different destinations by the 
>protocol and the entire world of SMTP servers
>ignore this and treats them as the same.

Many people believe that but it's not entirely true.

While most mail systems treat upper and lower case in local parts the same,
I have occasionally seen setups where you can send mail to sek...@example.com
and other capitalizations bounce.  It's not common, but it has its uses.

Also, as soon as you mention case folding, it gets conflated with a whole
bunch of other common but not universal address mappings like user+ext to
user and (since Gmail) adding and deleting dots.  Then there is the fetid
swamp of no return which is UTF-8 case folding and other normalization.

Hence I would tell people that if they make their names case sensitive
they are likely to be sorry, but I wouldn't try to enforce anything.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

[John Levine]

It appears that George Michaelson   said:
>>
>> > 4) Say in English prose that since the DNS ignores ASCII case
>> > distinctions, all versions of .alt are excluded from the DNS, but it's
>> > up to each non-DNS thing to choose which if any of the versions it
>> > uses and it how it interprets them.
>>
>> That feels best to me.
>>
>> --Paul Hoffman
>
>I don't see how this works in practice for the consequence of control
>moving to nsswitch.conf, and like processes.

I don't see any reason why that is our problem.

On my system at least, the only DNS queries that go through nsswitch
are ones starting from calls like getaddrinfo() or gethostbyname(). If
you're interested in MX or SRV or HTTPS or anything other than A and
 records, you're on your own. The switch to .onion doesn't use
nsswitch, but rather something a couple of levels up in a socket
proxy.

If people want to splice their stuff into this corner of the domain
name space it's up to them to figure out how to make it work.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

[John Levine]

It appears that Paul Hoffman   said:
>>> This document uses ".alt" for the pseudo-TLD in the presentation
>>>  format for the DNS, corresponding to a 0x03616c7400 suffix in DNS
>>>  wire format.  The presentation and on-the-wire formats for non-DNS
>>>  protocols might be different.
>>> "
>>> 
>>> I had to read this 3 times and I am still not sure what is important and 
>>> what not.
>> 
>> Doesn't this text also imply that the alt label is case-sensitive?
>
> Yes. We have at least three options:
>
>1) Pick one capitalization of "alt" and use the binary representation of that; 
>for example "alt".
>
>2) Pick two capitalizations of "alt" and use the binary representations of 
>those; for example "alt" and "ALT".
>
>3) Use all nine possible representations ("alt", "Alt", "ALt", ... "ALT")

4) Say in English prose that since the DNS ignores ASCII case
distinctions, all versions of .alt are excluded from the DNS, but it's
up to each non-DNS thing to choose which if any of the versions it
uses and it how it interprets them.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-alt-tld-16: please review

[John Levine]

It appears that Stephen Farrell   said:
>Hiya,
>
>On 19/08/2022 20:43, Warren Kumari wrote:
>> So, it is perfectly acceptable (in my view) for it to have:
>> 
>> ReferenceName
>> -
>> a-cool-document   foo.alt
>> another-documentfoo.alt
>> yet-another-doc  bar.alt
>
>I agree that such duplicate names are acceptable in this
>registry.
>
>I scanned the draft quickly and think it's good. (I'll try
>do a closer read in a few days.)
>
>Only thing with which I'd argue for now is that I think
>RFC required is a much simpler rule for the registry. Any
>other option will require some designated experts with
>some guidance for those DEs, and I'd expect it to be hard
>for us to agree what guidance to include in the draft or
>not, and I'd expect it to be hard to find DEs for this
>registry.

I don't see that as a big problem. Assuming we agree that the goal is
to have as complete a list as possible, the expert review would ask
questions like, is the reference in a plausibly stable place, e.g. not
a file:// URL, and does it describe something at least a little bit
like a name system and not, say, random slash fan fiction. (That last
bit is inspired by the constant stream of incoherent errata reports we
get.)

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...

[John Levine]

It appears that Eliot Lear   said:
> 1. Conflicts can be avoided between deployments of cooperating name
>systems; and

It seems to me that the key word here is "cooperating." Considering
how many projects squat on various bits of the DNS name space, we have
seen only one show any interest in the RFC route> I think it's fair to
assume most of the rest will continue to do what they're doing now if
we make them jump through our hoops. That's why we need to make it as
easy as possible to tell people what name you're using, i.e., FCFS
allowing duplicates.

> 2. A protocol switch is created in that label (xyz.gns.alt->gns,
>xyz.eliot.alt->eliot name service)

This is a swell research project but it is hard. Off the top of my
head I can think of at least three different places we do the protocol
switch now (socks for .onion, RRs for split horizon and homenet, fake
A/ for mDNS.) I doubt I've thought of all the places people do it
now and I am sure I have not thought of ones people might try in the
future.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[John Levine]

It appears that Paul Vixie   said:
>+1. noting, there should be a registry of second level domain style 
>names, maintained by IANA, with an RFC for each one describing what 
>protocol (whether Internet or otherwise) is used for names in that 
>"sub-tree", and references to permalinks where the non-tcp/53 non-udp/53 
>system is further described. ("build roads not walls.")

If my goal were to guarantee that people continue to ignore whatever process
we invent and just squat on whatever name they like, this is exactly how I
would ensure that happens.

The cost of writing and publishing an RFC is considerable, and the
benefit to someone with a non-DNS naming system rounds to zero. No,
we cannot promise that other people won't squat on their name. If it's
a good name, it'll get squatted. If not, it won't, but then why waste
time screwing around arguing with the IETF about it?

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...

[John Levine]

It appears that Paul Wouters   said:
>>> Meanwhile, IANA will have to host 60M entries in the .alt registry.
>> 
>> that would be a success disaster, and self limiting. to get traction, a new 
>> non-tcp/53 non-udp/53 would have to publish plugins for a lot of browsers
>and get uptake by libcurl and other places. that won't happen 60M times.
>
>People will pre-emptively “register”, it’s a whole new gold rush. I’ll just 
>get paulwouters.alt so others can’t. And especially like three
>letter ones like sex.alt. How are you going to release these ? First come 
>first serve when ?  What if someone sues over losing “unfairly”.  This is 
>straight up ICANN territory.

Right. If it's FCFS, I am sure I am not the only person who will be
waiting at the gate with thousands of preemptive registrations.  If there
is any kind of review, we have reinvented the beauty contests of RFC 6761
and ICANN, only badly and without a budget.

Those of us who remember usenet (or who are still on usenet) know when
the alt.* hierarchy was created, there was deliberately no process to
manage what got created. There was a great deal of garbage. Some alt
groups got and still have traffic, some don't. But at least the people
who manage the rest of the hierarchies didn't and don't have to waste
time pretending to manage it.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[John Levine]

It appears that David Conrad   said:
>-=-=-=-=-=-
>
>Eliot,
>
>On Aug 15, 2022, at 7:41 AM, Eliot Lear  wrote:
>> What I like about .alt (or whatever we end up calling it) is that it 
>> requires a single or small number of changes, not one change per name space.
>
>It creates a new namespace (*.alt), presumably one that is less contentious 
>than the root.  The allocation policy for names in that sub-namespace is
>undefined at this point.

In the discussions I've seen, the assumption is that the allocation
policy is "free for all." It is definitely not FCFS or any kind of
review. Maybe we would set up an IANA registry so people can let us
know about their .alt projects, but it would specifically allow
multiple entries with the same name.

>Leakage occurs because underlying systems are unaware of special handling 
>requirements for a particular name. I believe the assumption is that all
>resolvers (of all kinds) will be aware that they should not forward a name 
>ending with .alt to the DNS. This is a hard problem at Internet scale. As with
>.local, I’ll be surprised if declaring .alt a SUDN will have much impact on 
>the amount of leakage.

Yup. We also have very little basis on which to guess how much leakage
there is or would be and how much it matters to whom. The amount of
leakage to the root doesn't tell us a whole lot since I would expect a
great deal of leakage to end up at places like 8.8.8.8 and various DoH
providers which aren't likely to pass them up to root servers.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[John Levine]

It appears that Tim Wicinski   said:
>-=-=-=-=-=-
>
>as someone who looks at lots of caching resolver logs, you could add .local
>to this.
>But even those query loads are not what I consider a problem .

It's not the query loads, it's the data leakage.  I gather that the stuff
that leaks out to public DNS .CORP queries is quite amazing.

R's,
John

>On Sun, Aug 14, 2022 at 11:06 PM John Levine  wrote:
>
>> It appears that Stephen Farrell   said:
>> >Works for whom? I think it's entirely possible for the GNU
>> >people to come up with something they think works that does
>> >not break anything. Personally, I'm not convinced they're
>> >right about the first part, but I'm happy enough about the
>> >second.
>>
>> Depends how you feel about .GNS queries escaping into the
>> real DNS when they don't anticipate all of the ways people
>> will use their stuff.
>>
>> Dunno if they think that's a problem ("you need to configure
>> your software right") but I am pretty sure that people who
>> have seen what leaks from .CORP and .HOME believe it would be
>> a big problem.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[John Levine]

It appears that Stephen Farrell   said:
>Works for whom? I think it's entirely possible for the GNU
>people to come up with something they think works that does
>not break anything. Personally, I'm not convinced they're
>right about the first part, but I'm happy enough about the
>second.

Depends how you feel about .GNS queries escaping into the
real DNS when they don't anticipate all of the ways people
will use their stuff.

Dunno if they think that's a problem ("you need to configure
your software right") but I am pretty sure that people who
have seen what leaks from .CORP and .HOME believe it would be
a big problem.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[John Levine]

It appears that David Conrad   said:
>It seems to me that “the correct handling” of how an operating system or an 
>application distinguishes what protocol to use for domain name lookup
>(other than DNS) is outside of the bailiwick of DNSOP or the IETF.

I think we could have an interesting research project describing the
various levels at which one can switch out from DNS to something else,
e.g. application sockets like .ONION, pseudo A/ RRs like mDNS,
real RRs like split horizon DNS.  But that doesn't have much to do
with the issue at hand.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[John Levine]

It appears that Warren Kumari   said:
>-=-=-=-=-=-
>
>Warren’s meta-comment -[ Please read this ]-
>-
>I believe that there is still an open-mineshaft problem around Internet
>domain namespaces - what exactly they are, what is the DNS namespace, how
>one determines the boundaries of the space, how one switches namespaces,
>etc. We've take a few cracks at this nut — a partial list includes the IAB
>ENAME workshop, SUDN problem statement, drafts from Suzanne and Ed, the
>pain around .onion  (a fuller list is in [0]) -- but we haven't actually
>solved it. ...

Having read your message and largely agreed with it, my suggestion is that
we declare defeat and give up.

People come to us asking to reserve "good" names for them. As I said a
few messages ago, I think we could reserve random TLD strings like
.vhqnckwp without too much trouble, but nobody wants those. They want
memorable three or four letter strings.

For better or worse, allocating memorable strings is ICANN's job.
While I have my doubts about the details of the process, they do have
a process, and it's allocated over 1200 TLDs. It is not cheap, but
ICANN says they set the price to cover costs and again, while again I
have some doubts about the details, it's clearly the right order of
magnitude since they have spent about 85% of what they collected. I
don't see any benefit from us short circuiting their evaluation
process.

When we have tried to do something about memorable TLD strings, it has
not turned out well, viz. .corp, .home, and .mail.  (We are lucky that
the Allium Growers Promotion Board doesn't want .onion.)  Given the
history of failure, I think the sensible thing to do is to stop, which
means closing the Special-Use Domain Names registry.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

[John Levine]

It appears that Vittorio Bertola   said:
>1) Why should these people get for free something which everybody else is 
>required to pay $200'000 for?

Remember that $200K is just the starting point. Google paid $25M for
.APP, GMO paid $41M for .SHOP and Verisign paid $135M for .WEB.

In my experience, the people doing namespace experiments don't just want a name 
to to use. They
want a "good" name like .PET.

If we came up with a process to reserve random top level names like 
.lxaokwzyhedw 
or .nifacsyzudxt, I doubt we'd get much pushback from the ICANN community, but 
I 
also don't think any of the experiments would use them.

It has become egregiously clear that memorable top level names are worth a lot 
of money and I
see no basis for the IETF to give them away to anyone.  While I don't think 
.ALT is valuable
(nobody bid for it in any of the rounds to date) I also don't think anyone will 
use it because
it is not "good" enough.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

[John Levine]

It appears that Christian Huitema   said:
>AFAIK, the consequences would be minimal, as there is approximately zero 
>existing use of ".test" -- in constrast to say, ".local" or ".internal", 
>which both have very significant usage. Plus, whatever user they are 
>already warned.

If someone wants to squat or creatively reuse or whatever, there are
plenty of places to squat that are unlikely to collide with future DNS
uses. It is very unlikely that any of the ISO 3166 user defined codes
like .zz will be assigned.

But it seems to me that if this is not the DNS, it shouldn't try to pretend
that it is the DNS.

Use a name syntax that isn't hostnames, like something that includes
a string like .. or  !

Or set up GNS as its own name space and if they want to embed escapes
to the DNS in that name space, go ahead, and there's nothing for us to
say.

I still do not see any reason that the IETF should carve out pieces of
the domain name space for other people's experiments. There is plenty
of room for permissionless innovation on the Internet, even if it
means the programming to use it in a web browser or mail program is
harder. There are at least two widely used open source web browsers
and plenty of open source mail software. Stop asking for permission
and start writing code.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] URI RR labels derived from Enumservices (was: [Editorial Errata Reported] RFC8552 (7064))

[John Levine]

It appears that   said:
>Shouldn't the labels for Subtypes also go to this (initial) URI Registry?

Nope. The intent of this registry is to list all of the _tags that one
might run into when setting up a new thing, so you don't collide with
tags that other things already use. The subtype tags only appear to
the left of a type tag, so there's no collision problem.

It's the same reason that for SRV and URI we included the small set of
transport tags like _tcp and _udp but not the giant list of service
subtags like _smtp and _https.

My recollection is that we had two overlapping dicussions involving
IANA. One was that the names for URI records are the union of
transport names and enumservice type tags, and there is no provision
to keep the tag names from colliding if there are new ones.

The other was the general issue of multiple registries that are
supposed to stay in sync, and is it adquate to ask IANA to tell people
who update one registry that they should think about the other, also.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

[John Levine]

It appears that Paul Vixie   said:
>i'm particularly interested in whether the root zone should have an NS 
>for the private-label tld(s) (.alt or ._alt or whatever) with an NS of 
>"localhost" and a dnssec "opt out" indicator so that these private tlds 
>can fit into the authenticity infrastructure.

Why?  If you're going to hack in your local names, why wouldn't you hack
in your local DNSSEC anchors at the same time?

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

[John Levine]

It appears that Independent Submissions Editor (Eliot Lear) 
 said:
>  On the one hand, we need to find a 
>way for people to explore alternative namespaces that look a bit like 
>domain names.  On the other hand, we don't want to create problems with 
>user expectations.

It is fine for people to look at other ways to do naming on the
Internet, but that does not mean they get to squat on the DNS
namespace.

Look at the handle system or I guess DONA now. It has its own
namespace or numberspace, and it has its own way to look stuff up.
Some of their registry-like-things have made their own arrangements to
do DNS gatewaying, like https://dx.doi.org/10.2345/blah, which is fine
and neither our problem nor ICANN's.

GNS is welcome to set up their own name space and provide their own
resolution system. If they want to do a GNS->DNS gateway, that's fine.
But the DNS is the DNS, and things that aren't the DNS don't go there.

R's,
John

PS: Yeah, I know about .onion, but one unfortunate decision does not a policy 
make.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] punctuation follies, I-D Action: draft-ietf-dnsop-alt-tld-15.txt

[John Levine]

It appears that Peter Thomassen   said:
>
>
>On 6/27/22 22:05, John Levine wrote:
>> But there is a
>> great deal of software that expects the names it uses to look like
>> hostnames, and won't work with anything else.
>
>The software for new applications which would use a _foo pseudo-TLD namespace 
>is not yet written. It is for future applications, for which we
>can hope to push TLD-like use of things like "onion" into namespaces like 
>"_onion".

History suggests that you and I will both be dead before that software is
widely enough used for anyone to care.

>I see no reason why, if Tor was started today, the software written for it 
>should not be able to support _onion, if that was the BCP for doing
>it. Tor software would be written for that purpose at the time. Or am I 
>missing something here?

The particular issue for .onion was SSL certificates which use an
identifier with a syntax essentially the same as DNS hostnames. In
theory, we could ask the SSL people to change the rules to allow
_names, in practice, even if we could persuade the IETF to update the
spec, it would take a long time for the changes to percolate out into
the field. There is still plenty of software using TLS 1.1 which was
published in 2006 and deprecated a year ago.

You'd also need to update web browsers and the SOCKS proxies that are
usually used to connect the TOR sessions to the browsers. How much
time are you prepared to spend to persuade them all that they should
allow _label as the rightmost label?

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] punctuation follies, I-D Action: draft-ietf-dnsop-alt-tld-15.txt

[John Levine]

It appears that Michael StJohns   said:
>I suggest that reserving "_*" names is redundant as (I *think* - I 
>didn't go looking for the reference?) strings beginning with an 
>underscore can only be used in left-most components of a DNS name.

Dunno where you heard that, but it's completely not true.

Every SRV and TLSA record has a name that starts with two underscored
labels. Every DKIM key record has _domainkey in the middle.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] punctuation follies, I-D Action: draft-ietf-dnsop-alt-tld-15.txt

[John Levine]

It appears that Peter Thomassen   said:
>I am proposing to reserve all top-level underscore labels (_*) for special 
>use. Why?

While I don't think that reserving underscore names will break anything that is
not already broken, I also don't see what problem it solves.

Everything you say about *.alt is true, and most people who squat on
random top level hostnames will continue to do so. But there is a
great deal of software that expects the names it uses to look like
hostnames, and won't work with anything else. The argument for *.alt
is that if ICANN sells another round of vanity TLDs, as seems
depressingly likely, here's a hostname we promise won't have new name
collisions.

Since it is hard to imagine ever adding a name that isn't a hostname
to the public root, all of the _names are in practice reserved anyway.
But I don't recall ever seeing anyone squatting on a name that isn't
a hostname.  This should give us a hint.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

[John Levine]

It appears that   said:
>-=-=-=-=-=-
>
>
>Hi.
>
>During a meeting today of ROW (https://regiops.net), the I-D on CDS 
>bootstrapping by using a DNSSEC-signed name at name server
>zone (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/) 
>was discussed.
>In that discussion, it was mentioned that the current draft only supports 
>out-of-bailiwick name servers; I replied that the
>same principle could be applied to in-bailiwick name server by usage of the 
>reverse DNS zones for IPv4 and IPv6.

Urrgh. In principle, you can put anything you want in a reverse zone.
(Send mail to jo...@18.183.57.64.in-addr.arpa. and it'll work.)

In practice, I doubt that enough reverse zones are signed or that the
provisoning crudware that people use for reverse zones would work
often enough to be worth trying to do this. I did some surveys of 
zones and found that in-bailiwick NS are quite uncommon, only a few
percent of the ones in large gTLDs.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-01.txt

[John Levine]

It appears that libor.peltan   said:
>Alternatively, we may say that the RFC8078 bootstrapping is deprecated, 
>but still, it doesn't mean that we replace it.

That seems reasonable.  Does anyone actually do the current TOFU-ish bootstrap?

>>> Do no longer suggest NSEC-walking Signaling Domains. (It does not 
>>> work well due to the Signaling Type prefix. What's more, it's unclear 
>>> who would do this: Parents know there delegations and can do a 
>>> targeted scan; others are not interested.)

There's still a reference to NSEC walking in the penultimate paragraph in sec 
3.3.

I think it's still worth a suggestion in the trigger section that
operators allow AXFR of the signal information. While probing is just
as fast if there are only a few domains delegated to a NS, there are
name servers that have hundreds of thousands or millions of delegated
names.

I counted name servers in the .com zone, and found 93 with more than a
million each, a total of 120 million delegations. Even very slow AXFRs
of 93 zones are a lot faster than 120 million DNS queries.

Here's the first 20 of them:

4058923 nsg2.namebrightdns.com.
4058900 nsg1.namebrightdns.com.
3792278 dns1.registrar-servers.com.
3790659 dns2.registrar-servers.com.
3448893 ns1.gname-dns.com.
3448848 ns2.gname-dns.com.
2911454 jm1.dns.com.
2911442 jm2.dns.com.
2007121 ns1.bluehost.com.
2006794 ns2.bluehost.com.
1307459 ns1.dnsowl.com.
1307396 ns2.dnsowl.com.
1298775 ns3.dnsowl.com.
1174095 ns02.squarespacedns.com.
1174093 ns01.squarespacedns.com.
1135648 ns03.squarespacedns.com.
1135645 ns04.squarespacedns.com.
1119945 dm2.dns.com.
1119944 dm1.dns.com.
1118011 ns-cloud-c1.googledomains.com.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Technical Errata Reported] RFC7686 (6761)

[John Levine]

It appears that Peter van Dijk   said:
>> Corrected Text
>> --
>>    5.  Authoritative DNS Servers: Authoritative servers SHOULD NOT
>>    recognize .onion names as special and MUST NOT treat queries for
>>    .onion names differently from other queries.  By default,
>>    authoritative servers MUST NOT respond authoritatively to
>>    queries for .onion names.
>
>I like this even more.
>
>> The "By default" qualifier covers the case of a non-default
>> configuration (such as being configured to serve the root zone) where an
>> authoritative server would need to respond authoritatively for .onion
>> names.

It also allows wiggle room for kludges that special case .onion names and
set up proxies that respond on localhost addresses and synthesize an A
record to point to the proxy address.  (Did I say kludge?)

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

[John Levine]

It appears that Mukund Sivaraman   said:
>   Copyright (c) 2022 IETF Trust and the persons identified as the
>   document authors.  All rights reserved.
>
>By way of this, by removing the names of authors, isn't the copyright
>notice attributed to the (original) document authors also being removed?
>
>Clearly the text is not copyright of the new authors in this document: ...

Hi, trustee of the IETF Trust here. With rare exceptions that don't apply here,
when anyone submits an I-D or publishes an RFC, they grant a permanent license
to let anyone use the material in later drafts or RFCs in the IETF process.
There is no requirement for attribution or notice. We made that decision
deliberately, so that new drafts and RFCs can build on old ones. It also happens
that due to a treaty called the Berne Convention, the copyright notice on a
document no longer has any legal meaning at all.

While taking someone else's draft and putting your name on it as another draft
is legal, that's not the question here. It's whether it's ethical and something
we want to encourage. My impression is that in this case it was a
misunderstanding and I hope it will be sorted out shortly.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-dnssec-bootstrapping

[John Levine]

It appears that Benno Overeinder   said:
>Please review this draft to see if you think it is suitable for adoption 
>by DNSOP, and comments to the list, clearly stating your view.

I support adoption.  It fills a longstanding gap in DNSSEC deployment.

Will review, tweak text.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-sahib-domain-verification-techniques-03.txt

[John Levine]

This draft needs a lot of work but I think it could be worth adopting.

R's,
John


It appears that Shivan Kaul Sahib   said:
>-=-=-=-=-=-
>
>Hi all, we just published a new version of the DNS domain verification
>techniques draft. We've made some changes
>
>and have a new author (thanks Paul Wouters!)
>
>As mentioned last time, we're looking for DNSOP WG adoption.
>
>On Mon, 7 Mar 2022 at 11:06,  wrote:
>
>>
>> A new version of I-D, draft-sahib-domain-verification-techniques-03.txt
>> has been successfully submitted by Shivan Sahib and posted to the
>> IETF repository.
>>
>> Name:   draft-sahib-domain-verification-techniques
>> Revision:   03
>> Title:  Survey of Domain Verification Techniques using DNS
>> Document date:  2022-03-07
>> Group:  Individual Submission
>> Pages:  12
>> URL:
>> https://www.ietf.org/archive/id/draft-sahib-domain-verification-techniques-03.txt

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D An Extension to DNS64 for Sender Policy Framework SPF Awareness

[John Levine]

It appears that Klaus Frank   said:
>> If you want to continue to use DNS64 then you need the MTA or the SPF 
>> library to reverse the NAT64 encoding.
>If the above actually applies I'll replace the I-D with one that does 
>this within the SPF validator as then it would indeed be the better 
>solution. Do you by change know what WG would be best for that? It isn't 
>DNSOP is it?

No it isn't.  You don't need a new I-D, you just need to make the obvious fix 
to your SPF library.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D An Extension to DNS64 for Sender Policy Framework SPF Awareness

[John Levine]

It appears that Klaus Frank   said:
>I wrote an I-D for updating DNS64 to better work for MTA operators. ...

I strongly oppose this ill-considered proposal.  For one thing, it is very
rare for people to try to run mail servers behind DNS64.  SPF is fifteen
years old, and this is the first time anyone has brought up this issue.

For another, trying to guess which TXT records are SPF records and
rewriting them on the fly is unreliable and dangerous. The rewritten
record would always be larger than the original. If the rewritten
string exceeds the size limit of a text string or txt record, then
what?

But most importantly, there is a simple and reliable way to deal with
this issue. When an SPF library recognizes a NAT64 address, which it
can easily do with the method in RFC 8880, it turns the address back
into the equivalent IPv4 address and uses that in the SPF validation.
This will always produce the correct result, and needs no change to
existing standards. Having worked on a few SPF libraries, I can say
these changes would not be hard for anyone with a modest familiarity
with the code.

We've explained this several times already, dunno why we have to do so again.

R's,
John



>Name:    draft-frank-dns64-spf-extension
>Revision:    03
>Title:    An Extension to DNS64 for Sender Policy Framework SPF 
>Awareness
>Document date:    2022-02-14
>Group:    Individual Submission
>Pages:    6
>URL: https://www.ietf.org/archive/id/draft-frank-dns64-spf-extension-03.txt
>Status: https://datatracker.ietf.org/doc/draft-frank-dns64-spf-extension/
>Html: 
>https://www.ietf.org/archive/id/draft-frank-dns64-spf-extension-03.html
>Htmlized: 
>https://datatracker.ietf.org/doc/html/draft-frank-dns64-spf-extension
>Diff: https://www.ietf.org/rfcdiff?url2=draft-frank-dns64-spf-extension-03
>
>Abstract:
>    This document describes interoperability issues and resolutions
>    between DNS64 and SPF records for mail transfer agents.  This
>    document also aims to simplify the IPv6 migration for mail transfer
>    agent operators.
>
>    This document updates [RFC6147] and [RFC7208].
>
>
>-=-=-=-=-=-
>[Attachment type=application/pkcs7-signature, name=smime.p7s]
>-=-=-=-=-=-


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-03.txt

[John Levine]

It appears that Paul Wouters   said:
>On Jan 6, 2022, at 20:48, Paul Vixie  wrote:
>> 
>> 
>> 
>> George Michaelson wrote on 2022-01-06 16:50:
>>> for a 200 in 200,000,000 problem? Ban it.
>> 
>> i agree that we should ban it, but not on the basis of its infrequency of 
>> use. rather, on the basis of data provenance.
>
>Who wants to be the first to fail resolving adobe.net 

Since it's only a redirect to adobe.com, I doubt many people would care.

>Seriously though, this draft is not about banning certain deployments or not. 
>Its only concern is MAY vs SHOULD vs MUST require the
>found glue to be added to the response and potentially cause TC. 

We finally appear to be coalescing around the correct answer, MUST NOT.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-03.txt

[John Levine]

It appears that Wessels, Duane  said:
>In order to make progress on the glue-is-not-optional draft, we need the 
>working group to reach consensus on the requirement level
>for sibling glue (MUST, SHOULD, or MAY).
>
>The only situation in which a failure to include sibling glue leads to a 
>resolution failure is when there is a sibling glue cyclic
>dependency.  e.g.:
>
>  bar.test.  86400   IN NS  ns1.foo.test.
>  bar.test.  86400   IN NS  ns2.foo.test.
>
>  foo.test.  86400   IN NS  ns1.bar.test.
>  foo.test.  86400   IN NS  ns2.bar.test.
>
>A few months back I analyzed the zone files available to me via CZDS for 
>sibling glue.  Out of some 209,000,000 total delegations,
>222 of them had only sibling NS records in a cyclic dependency as above.  The 
>domains ADOBE.NET and OMTRDC.NET is one real-world
>example.

Looks to me like they're just broken:

$ dig @a.gtld-servers.net. adobe.net ns
;; QUESTION SECTION:
;adobe.net. IN  NS

;; AUTHORITY SECTION:
adobe.net.  172800  IN  NS  ns1.omtrdc.net.
adobe.net.  172800  IN  NS  ns2.omtrdc.net.

;; ADDITIONAL SECTION:
ns1.omtrdc.net. 172800  IN  A   66.235.157.6
ns2.omtrdc.net. 172800  IN  A   66.235.157.7

$ dig @ns1.omtrdc.net. adobe.net. ns
;; QUESTION SECTION:
;adobe.net. IN  NS

;; ANSWER SECTION:
adobe.net.  900 IN  NS  ns-1.adobe.net.
adobe.net.  900 IN  NS  ns-2.adobe.net.

;; ADDITIONAL SECTION:
ns-1.adobe.net. 900 IN  A   66.235.157.6
ns-2.adobe.net. 900 IN  A   66.235.157.7

(Note that they're the same servers with different names.)

I'm not sure how you'd do this, but do you have any idea how many domains have 
NS cycles
across parallel zones that don't work, e.g.:

  foo.tld1. IN NS ns1.bar.tld2

  bar.tld2. IN NS ns2.foo.tld1.

R's,
John

PS: My preference is still "don't do that."
-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] How Slack didn't turn on DNSSEC

[John Levine]

It appears that Viktor Dukhovni   said:
>However, I do think that the skill level required need not always
>be or remain "wizard".  They had some bad luck running into a not
>fully baked stack on the provider end.

While they should have caught the apex CNAME, I can't really blame
them for not anticipating that AWS Route 53 would have buggy
DNSSEC handling.  Wildcards are unusual but they're not *that* unusual.

I realize the problem with test suites that the test suite tends to
become the de-facto spec, but it might be nice to come up with a list
of tests that check for famous bugs.

R's,
John


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] How Slack didn't turn on DNSSEC

[John Levine]

This blog post has been making the rounds. Since it is about a
sequence of DNS operational failures, it seems somewhat relevant here.

https://slack.engineering/what-happened-during-slacks-dnssec-rollout/

tl;dr first try was rolled back due to what turned out to be an unrelated 
failure at some ISP

second try was rolled back when they found they had a CNAME at a zone
apex, which they had never noticed until it caused DNSSEC validation
errors.

third try was rolled back when they found random-looking failures that
they eventually tracked down to bugs in Amazon's Route 53 DNS server.
They had a wildcard with A but not  records. When someone did an
 query, the response was wrong and said there were no records at
all, not just no  records. This caused failures at 8.8.8.8 clients
since Google does aggressive NSEC, not at 1.1.1.1 because Cloudflare
doesn't.

They also got some bad advice, e.g., yes the .COM zone adds and
deletes records very quickly, but that doesn't mean you can unpublish
a DS and just turn off DNSSEC because its TTL is a day. Their tooling
somehow didn't let them republish the DNSKEY at the zone apex that
matched the DS, only a new one that didn't.

It is clear from the blog post that this is a fairly sophisticated
group of ops people, who had a reasonable test plan, a bunch of test
points set up in dnsviz and so forth.  Neither of these bugs seem
very exotic, and could have been caught by routine tests.

Can or should we offer advice on how to do this better, sort of like
RFC 8901 but one level of DNS expertise down?

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

[John Levine]

It appears that Paul Wouters   said:
>I've read the draft, and it is an interesting idea. Some thoughts I had:
>
>- Is it really needed to do hashing? Do we really expect domain names to
>   hit the 63 or 255 limit ? 

Probably not.  There was also some thought that this makes it harder for
tourists to guess the delegated zone names, not sure if anyone would care.

>- I would like to see some text on removing the records too once the
>   child gained its DS record.

That really needs to be about scaling issues.  If your NS serves three
zones and you leave in the _boot records, who cares.  But there are
NS that serve three million zones and I think we would all like to
avoid long useless NSEC walks.

>- Should it be explicitly noted that in-bailiwick domains are not
>   supported?

Yes, I thought that was in there already.  I did some counts in TLD
files and found that in practice very few 2LDs use in-bailiwick NS.
We should document it but it's not a big deal.

>- It puts a constraint of the nameserver being in a zone that is DNSSEC
>   enabled. This is currently not required (though very often the case
>   anyway)

The point of this is to do a DNSSEC bootstrap that is fully DNSSEC
validated.  If the _boot record doesn't have to be signed, you might
as well just use the CDS from the child server.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Bailiwick discussion for draft-ietf-dnsop-rfc8499bis

[John Levine]

It appears that Paul Wouters   said:
>The suggestion by Tony Finch:
>
>   * Sibling zones: two zones whose delegations are in the same
> parent zone.
>
>   * Sibling glue: addresses of nameservers that are in a sibling zone.

So far we agree (which when it's Paul and me, is really saying something.)

> Sibling glue is usually the glue that the DNS would require for that
> sibling zone, but in some cases the requirement lies elsewhere, ...

This is where we always go off the rails.  There seem to be two mutually
exclusive interpretations of sibling glue:

1 - it's a small and entirely optional twiddle to speed up or skip
recursing into the sibling zone

b - it's an essential part of the response because it's the only way to
resolve a reference loop.

I've already said my piece about which of these makes sense and which is a cruel
joke, but if we're going to talk about sibling glue at all, we need to decide
which one we mean.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DS glue for NS draft

[John Levine]

It appears that Brian Dickson   said:
>-=-=-=-=-=-
>
>This is the work I will be submitting in DNSOP.
>
>This is what has been described as a “hack”, but provides a needed validation 
>link for authoritative servers where the latter are in
>signed zones, but where the served zones may not be signed.
>
>NB: It overlaps with the recent DPRIVE draft that Ben S submitted recently.
>
>It will likely be the case that those overlaps need to be reconciled, based on 
>use cases and scope.

It looks to me like the main difference between the drafts is that Ben's scheme 
uses one new 
faux algorithm and puts the rrtype inside the encapsulated data, while yours 
uses one per rrtype.
The goals look a little different but other than where the rrtype is encoded 
the mechanisms
look the same.

In both drafts I would like to see clearer explanations of what you do when the 
signed glue
disagrees with their authoritative non-glue versions.  I'm having some trouble 
figuring out
exactly what "authoritative" means here.

R's,
John


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Dropping the draft "The DELEGATION_ONLY DNSKEY flag"

[John Levine]

It appears that Paul Wouters   said:
>On Thu, 5 Aug 2021, Tim Wicinski wrote:
>
>> Subject: [DNSOP] Dropping the draft "The DELEGATION_ONLY DNSKEY flag"
>
>> This came up in the poll, but also the discussion on priorities.  There 
>> seems to be
>> strong feelings on dropping this draft.   We adopted with the idea that if 
>> we could
>> not find WG consensus, we were not going to advance it, and that seems to be 
>> the case.
>
>We had several people in favour of the experiment, and Joe Abley against it.

I know I have repeatedly said why this draft is not useful, and I don't recall 
anyone but
you who still wants it.

Perhaps we could let our WG chairs do the chairing.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Moving forward on draft-ietf-dnsop-private-tld

[John Levine]

It appears that Joe Abley   said:
>Hi Paul,
>
>On Jul 30, 2021, at 14:55, Paul Wouters  wrote:
>
>> We literally had a survey to ask us “what should we kill because we don’t 
>> have enough time”
>
>I don't think that's exactly the question I saw, but perhaps I misremember. 
>
>For what it's worth (and as you know from our conversations about it on this 
>list) I disliked your delegation-only draft on its merits and not because of 
>lack of time. 

Same here.  I think the WG had plenty of reasons not to advance it.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

[John Levine]

It appears that Paul Wouters   said:
>On Tue, 27 Jul 2021, John R Levine wrote:
>
>> Well, OK.  How about this?
>>
>>   foo.example NS ns.bar.example
>>   ns.foo.example  2001:0DB8::000b::1
>>
>>   bar.example NS ns.abc.example
>>   ns.bar.example  2001:0DB8::000b::2
>>
>>   abc.example NS ns.def.example
>>   ns.abc.example  2001:0DB8::000b::3
>>
>>   def.example NS ns.foo.example
>>   ns.def.example  2001:0DB8::000b::4
>>
>> (I would have gone all the way to ns.xyz.example but it's tine for bed here)
>>
>> We don't try to make NS loops work across zones, so I don't see the point of 
>> sorta kinda trying to make them work sometimes.
>
>You still mis thepoint. In the case of def.example needing
>ns.foo.example, the server can just check if it has glue for
>ns.foo.example. It does, so it returns it. It is not going to
>check whether or not this is a silly loop to .xyz.example or
>beyond. There is no point in knowing that. It has an NS record
>pointing to X. It has a glue record for X. So it includes the glue
>record X.

OK, so I ask for foo.example and I get 

; answer
 foo.example NS ns.bar.example
; additional
ns.bar.example  2001:0DB8::000b::2

Does it check that's the right value for ns.bar.example?  How about with 
DNSSEC?  I suppose

I still don't see the benefit of trying to make some loops work when we know 
that we
can't make cross-zone loops work.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop