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

[John R Levine]

On Fri, 10 May 2024, Paul Wouters wrote:

On May 10, 2024, at 05:36, jab...@strandkip.nl wrote:


I'm interested in where this guidance comes from.

RFC 2782 to me is the grandfather of underscore labels, and it pretty much goes 
out of its way to encourage a hierarchy of underscore labels to anchor SRV 
records under, e.g. under _tcp.name and _udp.name.


But if you look at more recent RFCs such as TLSA records, it is narrowed to one 
specific protocol and port, eg _25._tcp.mx.nohats.ca


But this isn't the same thing.  The two tags on SRV and TLSA records are 
consecutive labels on single records.


As you are both surely aware because you have read the draft, in this 
case, the _signal record sits atop an entire subtree, e.g.


 _dsboot.example.co.uk._signal.ns1.example.net
 _dsboot.example.co.uk._signal.ns2.example.org

means that the name servers ns1.example.net and ns2.example.org have 
bootstrap info for example.co.uk.  Since parent scanning for every 
possible combination of NS and domain would be rather slow, the draft has 
suggestions such as putting the _signal name in a separate zone that 
parents can walk with NSEC.  There might be other tags than _dsboot for 
things like synchronizing multi-provider DNS updates, but it's all DNSSEC.


Needless to say, this is quite DNSSEC specific and even someone invents 
some other thing that uses two domain names in a similar way, it's 
unlikely that you'd want to put it all in the same zone.  So I hope we 
agree to call it _dnssec or something like that.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

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

[John R Levine]

Actually, we are developing an unrelated scheme that has need of the same 
zone structure for signaling but not involving DNSSEC itself, and would see 
some advantage in utilizing the same standard top level underscore naming for 
signaling use in general.


Would you want to put the signal info in the same zones with the DNSSEC stuff? 
If not, you don't want the same tag.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

[John R Levine]

On Thu, 2 May 2024, Scott Morizot wrote:

I think we need a clean update to RFC 8624 first that includes 
instructions to IANA to update the table. I don't think the current 
draft does that very well. And since the IANA table already has a Zone 
Signing column, I think we just want to change that one so it has more 
than a yes/no option per algorithm and then add a Validation column.


I think we're agreeing that it would be a good idea to continue to 
discourage SHA1, but not a good idea to surprise people by making it 
suddenly stop working, a la Redhat.


R's,
John

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

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

[John R Levine]

On Thu, 2 May 2024, Scott Morizot wrote:

On Thu, May 2, 2024 at 7:32 AM John R Levine  wrote:


MUST NOT is advice on how to interoperate, not on how to write software
tools.  It's up to the zone operator to follow the advice, not to the tool
provider to hold them hostage.



??? RFC 8624 is explicitly guidance to implementers not  operators. The
"MUST NOT" means MUST NOT implement in a conforming implementation of
either signing or validation software. That's not an opinion. It's what the
text says.


The word "software" does not appear in RFC 8624.  I think it is evident 
from the text that the implementers are the people using DNS software and 
signing the zones.


Ondřej and Paul wrote the RFC so perhaps they can tell us what they meant.

R's,
John

PS: I don't think there is much practical difference between the NOT 
RECOMMENDED in 8624 and a draft that says MUST NOT to signers, so I would 
also be perfectly happy to leave things as is and abandon the draft.


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

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

[John R Levine]

I'm with Peter, I do not see a MUST NOT as requiring vendors or operators
to do stupid stuff.


For my understanding, do you mean to say that if we publish that a signer
MUST NOT generate signatures using algorithms 5 and 7, then the signer can
just do that if it generates and annoying warning each time you sign?

To me that sounds more like a SHOULD NOT.


MUST NOT is advice on how to interoperate, not on how to write software 
tools.  It's up to the zone operator to follow the advice, not to the tool 
provider to hold them hostage.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

On Sun, 17 Mar 2024, Shumon Huque wrote:

The draft allows (but does not proscribe) NXDOMAIN to be inserted into
the Rcode for non DNSSEC enabled responses. I guess the main reason
for not being proscriptive was what I mentioned - there were deployments
in the field that didn't. ...


You're certainly right that there is software that sends NXDOMAIN when 
NODATA would be appropriate or vice versa.  (rbldnsd which is widely used 
in dnsbls has been a notable example which I think is now mostly fixed, 
due to giving wrong answers to minimized queries.)  But I think we're 
agreeing that it's better to confirm this is bad practice and encourage 
software to conform than to add yet another hump on the camel.


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 R Levine]

On Wed, 13 Mar 2024, Mark Andrews wrote:

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.


Actually it is a problem.  It results in lots of additional lookups.
That in turn results in amplification bug reports being reported from
universities looking for the latest way to abuse the DNS to launch
DoS attacks.  And it is not 3 CNAMEs, you are looking at 5+ CNAMEs
today.


Whatever it is, it's a lot more than one, and we've been able to deal with it.

I agree with you that a lot of CNAME applications could better be done 
another way (someone pointed out that Cloudflare does CDNs with no CNAMEs 
at all) but at this point the costs of forcing people to use fewer CNAMEs 
are unlikely to be worth the pain.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] [Ext] About key tags

[John R Levine]

On Sat, 2 Mar 2024, Peter Thomassen wrote:

On 2/29/24 18:06, Paul Wouters wrote:
 (If no action is taken, malicious activity might follow now that it is 
described, but I have not heard of a historical case of it.) 


This attack was more or less described five year ago: 
https://essay.utwente.nl/78777/ 


They didn’t get to the same amplification levels but if attackers had been 
interested, they could have picked it up as a tool to improve. scripts to 
run were attached to the paper.


My take is that with the current mitigations (tolerate a very small but 
nonzero number of keytag collisions), it's unlikely that this will be 
exploited in any significant way, as the attacker's gain is very limited.


I think we're in violent agreement here.  The current mitigations are 
adequate, and nobody has offered a reason to believe that if we made 
things tighter, e.g., no keytag collisions at all, that it would make much 
practical difference.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] [Ext] About key tags

[John R Levine]

You don’t perform a verify if the time window is invalid. The same as you don’t 
perform a verify if the tag doesn’t match.  Mind you it’s completely pointless 
to have multiple time ranges. The RRset and it’s signatures travel as pairs. 
All the key rollover rules depend on that.


I agree it doesn't make much sense to have two signatures with overlapping 
time windows but the spec allows it.


For about the hundredth time, the woy you deal with any of this is 
resource limits, not trying to invent new rules about stuff we might have 
forbidden if we'd thought of it 20 years ago.


R's,
John

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

Re: [DNSOP] [Ext] About key tags

[John R Levine]

Remember that the keytags are just a hint to limit the number of keys
you need to check for each signature. If I have a zone with 300
signatures per key, it's still going to take a while to check them all
even with no duplicate tags. It won't be as bad as the quadratic
keytrap but it'll still be annoying.


If key tags are unique, then a validator can just discard anything that
has multiple signatures with the same key tag.


No, that's not how it works.  The signatures might have different time 
ranges or otherwise be different but still plausibly valid.  Please review 
RFCs 4034 and 4035.


R's,
John

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

Re: [DNSOP] [Ext] About key tags

[John R Levine]

Technically only a SHA-2 hash of the key would need to be there. If somebody
can create a SHA-2 hash collision then the world has bigger problems than
a DoS on DNSSEC validation.


How hard would it be to add a possibility for another key algorithm?


Beyond the change to the specs, it would require significant software 
changes to every piece of software in the world that signs or validates 
DNSSEC.  I figure we could have it widely adopted by the 2050s.


We have established that the benefit would be negligible, and caches would 
still need to have defensive checks against excessive or duplicate keys 
and signatures.  Let's talk about something else.


R's,
John

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

Re: [DNSOP] [Ext] About key tags and collision numbers

[John R Levine]

On Wed, 28 Feb 2024, Shumon Huque wrote:

Banning keytag collisions outright today would not be a good idea - we risk
rendering some sights unresolvable through no fault of their own. DNSSEC
already has plenty of detractors, and we don't want to give them more
ammunition by creating problems in the ecosystem that can be easily
avoided. I think writing a BCP telling folks how to avoid collisions would
make sense though (and yes, it needs to cover the multi-signer case too).


The multisigner case is a database update problem which is surprisingly 
hard to get right.  Either you need locked updates which are slow and 
subject to hanging, or you need to detect collisions and retry, which has 
its own problems (BTDT).


If we can live with small numbers of collisions, the whole problem is a 
lot more tractable.


Too bad there's no room for grease in DNSKEYs.  If you were allowed to add 
a byte or two of noise, you could constrain the range of the key IDs you 
generated, which would let you partition the ID space among multiple 
signers. That would be (other than the grease kludge) an elegant way out.


R's,
John

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

Re: [DNSOP] [Ext] About key tags

[John R Levine]

On Thu, 29 Feb 2024, Mark Andrews wrote:

If it is forbidden in the protocol, it might still happen.


Ed, your reasoning is off.  The point of forbidding is to allow the validator 
to safely stop as soon as possible when it is under attack.


We're going in circles here.  You want to stop at 2 some time in the 
future after we've changed the spec.  Ed and Shumon and I want to stop at, 
say, 10, right now.  I've never written a DNSSEC validator so I don't know 
how different those are in practice but I'd be surprised if it were very 
much.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] [Ext] About key tags and their infrequent collisions

[John R Levine]

On Wed, 28 Feb 2024, libor.peltan wrote:

Dne 27. 02. 24 v 21:24 John Levine napsal(a):

The total number of domains where I found duplicate tags was 105.

As I said earlier, is while I appreciate such research, I warn against 
misinterpreting it. The main point isn't about the zones that are currently 
experiencing a keytag-conflict; it's about the zones where there is a 
potential threat that they might do tomorrow (considering the case when many 
mainstream validating resolvers would start enforcing strong 
keytag-conflict-intolerance).


Sure, but my point is that you don't need to overthink this.  If your 
cache stops when it sees 8 or even 5 colliding IDs or signatures, the 
chance that you will fail any real queries is vanishingly small.  You can 
mitigate the problem without any complicated thread or schedule management 
or protocol changes.  You'll still handle the real cases where a few IDs 
collide by accident.


In retrospect it would have been a good idea to pick a less lame checksum 
but I suppose if it's good enough for TCP, it's good enough for DNSSEC.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] [Ext] About key tags

[John R Levine]

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.


If you forbid in the protocol the tools will be fixed to prevent it
occurring when signing and the validators don’t have to be prepared
to play trial and error when there are duplicate tags in a DNSKEY
RRset. ...


That's all true, but people will publish them anyway, so the tools need to 
defend against them no matter what the protocol says.  Based on what I've 
seen, pairs of colliding tags appear innocently, larger numbers don't, so 
you set the limit in the single digits.


Is it really so much harder to write code that allows, say, three 
signatures and three IDs than code that only allows one?  As I hardly need 
point out, the process cost of changing the protocol is high, and it will 
take approximately forever for the long tail to notice.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

On Tue, 27 Feb 2024, Toerless Eckert wrote:

Me ? No.


Why do we care whether ICANN will delegate .INTERNAL?  They'll never 
delegate .AA or .ZZ either, and nobody sees that as a problem.


R"s,
John



On Tue, Feb 27, 2024 at 01:22:43PM -0500, John Levine wrote:

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.





Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] DNSBL performance optimization, was QNAME minimization can be better

[John R Levine]

TL;DR: (IPv4) The benefit of NSEC is fewer queries to the auths which would
return NXDOMAIN answers, which improves overall DNSBL lookup performance.
It also avoids exploding the negative cache of the resolver.


Funny you should mention that.  About ten years ago I was trying to figure 
out how IPv6 DNSBLs would work.  I came up with a variety of ideas, such 
as one where I put the entries in a B-tree stored in the DNS.  (It worked 
but its performance was no better than the obvious rDNS like approach.) 
It occurred to me that the IPv6 DNSBL address space was likely to be 
sparse, so I suggested on this list, how about signing the DNSBL zones and 
then the cache can synthesize NXDOMAIN responses from the NSEC records.


I was firmly informed that I was a moron, that was a stupid idea, and if 
you want the right answer, you should ask the authoritative servers.  Now 
we have RFC 8198 so I guess we are all morons, or something.


Using NSEC to fill the gaps is still a reasonable idea but the stunt 
servers that serve most DNSBLs don't yet do DNSSEC, and if the stats I've 
seen are to be believed, most of the net still doesn't look at DNSSEC even 
if it's available.


FYI, you can't use most DNSBLs through large public resolvers like 
8.8.8.8.  The DNSBLs use a freemium model where the largest users pay 
(which I can assure you they do for high quality DNSBLs) while providing 
free results to everyone else, and if they allowed people to use the 
public resovers, that wouldn't work.  Large means very large, the 
resolvers at most hosting providers have no problem.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] QNAME minimization can be better, or New Version Notification for draft-levine-qmin-performance-00.txt

[John R Levine]

On 14/11/2023 00:56, John R Levine wrote:

Once again, I really wish people would stop blaming the victim.


That's not useful language. DNSBLs fulfill a purpose but are not
victims. People whose privacy is exposed via network traffic are
not correctly described as victims but are nonetheless liable to
suffer via, e.g. more spam or even attack following a data leak,
as a result.


As I explain in my draft, it should be quite possible to use QNAME 
minimization and not send a lot of useless traffic to DNSBLs.  We created 
this problem, we can fix it, and it makes us look like jerks to say that 
other people should fix problems we created, when we can fix them 
ourselves.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] QNAME minimization can be better, or New Version Notification for draft-levine-qmin-performance-00.txt

[John R. Levine]

On Mon, 13 Nov 2023, Ben Schwartz wrote:


What about updating RFC 5782 to remove the "."s?  The "."s don't seem to help 
in any way here (unlike reverse zones, where they enable useful delegations).


PS:  Some DNSBLs use stunt servers that synthesize the answers, but some 
are normal DNS zones.  In those cases, if they list, say, 12.34/16, the 
zone will contain *.34.12.dnsbl.whatever.  It is simply false to assert 
that the dots are not useful.


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] QNAME minimization can be better, or New Version Notification for draft-levine-qmin-performance-00.txt

[John R Levine]

Looks good.  I am hoping that we can reduce or at least prioritise the
different suggestions before it is finalized.


I am hoping someone has more data so if there are other places where 
minimization causes performance problems, we can recognize them and fix 
them.



"little or decrease" -> "little or no decrease"




Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] QNAME minimization can be better, or New Version Notification for draft-levine-qmin-performance-00.txt

[John R Levine]

What about updating RFC 5782 to remove the "."s?  The "."s don't seem to help 
in any way here (unlike reverse zones, where they enable useful delegations).


Once again, I really wish people would stop blaming the victim.

Rather than telling 100,000 mail servers around the world to change the 
way they work to fix a problem we created, how about asking the five DNS 
packages everyone uses to fix this performance bug so as everyone does 
routine software updates, the problem goes away?


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] QNAME minimization, we screwed up and it's your problem

[John R Levine]

On Sat, 11 Nov 2023, Paul Wouters wrote:

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.


It is totally reasonable for protocols and software and configurations 
to need adapting over time. Especially in light of privacy and security 
concerns.


That's why, now that we are aware that minimization causes this kind of 
problem, we should fix it.  It's not like it's that hard to do.  As I said 
a few messages back, blaming the victim is not a great plan.



Write a draft and we have something to discuss.


Well, sure.  My flight was cancelled and I'm stuck in Frankfurt so I might 
as well do it this afternoon.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] QNAME minimization: we screwed up but it's your problem

[John R Levine]

On Fri, 10 Nov 2023, David Conrad wrote:

DNSBLs have been around a lot longer than QNAME minimization.


Not sure that’s relevant — I presume you’re not suggesting DNSBLs are a 
predominant use of the DNS.


In the overall Internet, no, but within the e-mail world it's probably the 
majority of the traffic since mail servers do multiple DNSBL checks on 
every incoming message.



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.


I thought the point of QNAME minimization was to improve privacy.


In many cases it does that.  Unfortunately, for DNSBLs (and maybe some 
other applications) it is in effect a DDoS with no privacy improvement at 
all.


As I think I said a few messages ago, I hope people have done traffic 
studies so we can see if there are other situations like this that we 
could fix at the same time.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] QNAME minimization is bad

[John R Levine]

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.


I must confess that I do not see what is suggested in this thread
which is not already in section 2.3. Unbound implements some of the
RFC ways, see its iterator/iterator.h (all parameters named
*MINIMISE*).


If you see a name that is four all-digit labels and it's not in 
in-addr.arpa, stop minimizing and just send the query.  Similar for 18 hex 
digits not in ip6.arpa.  I realize these are specific cases but at least 
in the mail world they are very common ones and minimization more than 
doubles the traffic DNSBLs would otherwise get.


Again, there might be others.  Data eagerly sought.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

[DNSOP] QNAME minimization is bad

[John R Levine]

Well, not always bad but sometimes.

A friend of mine who works on DNSBLs wrote yesterday (quite by 
coincidence, unware that there's a meeting this week) asking if anyone has 
thought about this problem: DNSBLs have the same form as rDNS, IPv4 names 
all start with four labels containing digits, IPv6 names start with 
sixteen single character hex digit labels.  In nearly every case the 
entire DNSBL is in a single zone so minimization wastes a lot of queries 
crawling down the zone.  Queries to DNSBLs are fairly randomly distributed 
so 8020 doesn't help much.  If a cache gets to a point where the remaining 
labels look like this, it is almost certainly rDNS or a DNSBL and the 
cache should stop crawling and send the full query.


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.


There are probably others I haven't thought of; who's done research on this?

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

Named at least will forward UPDATE to the primary servers.  It’s off by default 
because it hides the source address and UPDATE may
be restricted by IP address but it works with both TSIG and SIG(0).  This is 
standards defined behaviour.  TSIG was designed to
support this.  SIG(0) requires a bit more care as the QID is coved by the 
SIG(0).  Adding forwarding of NOTIFY(CDS), NOTIFY(CDNSKEY)
would be trivial.  Directing it to another “server" would also be trivial.


Keep in mind that this is a new and different use of NOTIFY for CDS rather 
than AXFR.  The message format is the same but the flow goes in a 
completely different direction, from child zone to parent, not primary to 
secondary.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

On Thu, 9 Nov 2023, Joe Abley wrote:

 If we can get the registrars and registries to go for it, registry forwarding 
is fine with me, but I don't think it would be a good idea to specify it unless 
we are confident that people are willing to do it.


To be honest I have my doubts that any of this is worth doing at all; I think 
it would be far better to forget about DNS-centric approaches and put effort 
instead into broadening the provisioning channels around domain registrations 
and management to incorporate DNS operators. If I'm right and none of this is 
going anywhere anyway, then we might as well be expansive in our design :-)


I have a lot of sympathy for that position.  It's come up in the Other 
Place too.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

On Thu, 9 Nov 2023, Joe Abley wrote:

Apropos Joe's message, the child could hypothetically try and send the NOTIFTY 
to the parent SOA, e.g. a.gtld-servers.net for .com or .net.  But those are 
clouds of anycast servers and even if you can get that to work, they belong to 
the registry while the notify needs go go to the registrar so it can update the 
registry via EPP.


I don't agree that it's impossible to use an anycast target for this, any more 
than it's impossible to distribute any service using anycast.


I don't think it's impossible either, but it's swatting a fly with a 
motorcycle.  As far as I know the anycast mirrors do not feed stuff in 
realtime back to their primaries and this would be quite a change, not to 
mention needing non-standard hacks to their DNS servers.  (That's "reverse 
anycast".)



As far as communication with registrars goes, the registry operator is actually 
ideally placed to relay general messages to registrars. I'm not sure why this 
is being discounted. They already do so for other purposes.


At that other I* organization we were led to understand that registrars 
get unhappy when the registry interacts directly with their customers.  If 
we can get the registrars and registries to go for it, registry forwarding 
is fine with me, but I don't think it would be a good idea to specify it 
unless we are confident that people are willing to do it.


Re stealth, the place you send the NOTIFY is in practice going to be a 
server that just does the update stuff, not a public or stealth DNS 
server.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

On Wed, 8 Nov 2023, Brian Dickson wrote:

The target for a NOTIFY would necessarily be found in the SOA record of the
registrant's zone, not the parent's zone. I think that's where the
confusion has arisen.


There's definitely confusion here but I don't think it's mine.

The child (registrant) puts a CDS record in its zone, and then it wants 
the parent (registry and/or registrar) to look at it and update the DS in 
the parent (typically TLD zone) so it needs to notify the parent to tell 
it to take a look. The child's SOA lists the child's own primary NS, not 
the parent's, so notifying itself won't help.


Apropos Joe's message, the child could hypothetically try and send the 
NOTIFTY to the parent SOA, e.g. a.gtld-servers.net for .com or .net.  But 
those are clouds of anycast servers and even if you can get that to work, 
they belong to the registry while the notify needs go go to the registrar 
so it can update the registry via EPP.


One might wave one's hands frantically and imagine there is some way to do 
reverse anycast plus magic forwarding to the registrar, but I am not going 
to go there.



BTW, this use of registrant's zone's SOA.MNAME supports both the non-hidden
master/signer, and the hidden master/signer use cases, AFAICT.


This makes no sense at all.  Beyond the fact that it's the wrong SOA, the 
point of a hidden primary is that it's hidden.  Putting it in an SOA would 
spill the beans.


ICANN's CZDS distributes copies of TLD zone files which they fetch via 
daily AXFR from stealth zone primaries.  For a while, they were just 
dumping the AXFR output into the files including a comment that had the 
address of the primary.  They were very embarassed when I told them I knew 
where all the stealth primaries were because they told me, and they 
promptly edited the comments out.  People care that stealth is stealthy.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

On Wed, 8 Nov 2023, Joe Abley wrote:

I think the idea is that these two existing and well-implemented mechanisms 
should be considered first to see if they fit before anybody goes to the 
trouble of inventing new ones.


The most likely use case for this stuff is for a domain registrant to 
update the DNSSEC info in a TLD, and I'm pretty sure you know more about 
the way .ORG is set up than I do. Since the registrant is a customer of 
her registrar, that's where the NOTIFY needs to go.


How well do you think it would work to send NOTIFY to the anycast mirrors 
that serve the .ORG zone?  FWIW, even for my own tiny DNS setup, I use 
NOTIFY to sync with a mirror at a nearby ISP and I have to notify his 
hidden primary which does not appear in any NS or SOA records.


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 R 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?


Neither of the mechanisms Paul suggested require manual configuration.


I am clearly missing something here.  The child zone wants to notify the 
parent to tell it to pick up some new DNSSEC keys or something.  The 
parent's NS are A, B, and C, but the notify needs to go to stealth server 
X or maybe registrar server R.


How does the child know where to send the notification?

R's,
John:

PS: I see that 1996 says:

  Stealth   A
   stealth server will only be known by other servers if
   they are given static configuration data indicating
   its existence.

   Notify Set  set of servers to be notified of changes to some
   zone.  Default is all servers named in the NS RRset,
   except for any server also named in the SOA MNAME.
   Some implementations will permit the name server
   administrator to override this set or add elements to
   it (such as, for example, stealth servers).

That sure looks like manual configuration to me.

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

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

[John R Levine]

I thinnk you're agreeing that we should add notifications even though we 
can imagine a wide range of so-far nonexistent ways to limit the cost of 
scanning.


My thought is that the notify is for the domain to be signed, so there's 
no scanning, just parent checks to see whether it likes the new keys and 
if so, installs them.  I suppose the notification might get lost, but 
sending another one is likely to be faster than waiting for a scan.



On Fri, Oct 13, 2023 at 10:48 AM John Levine  wrote:


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 believe a more concise summary of the Notify vs CDS would be:

  - Notify is better than scanning
  - This is analogous to "Winning $1,000,000 in the lottery is better than
  winning $10."

It also is more helpful to consider the parties and benefits of using
Notify.
CDS scanning will always be necessary, for the use cases relevant here.

  - Notify does not impact the scanning activity at all.
  - Notify *does* reduce the time for a *specific* domain to have the CDS
  processing done.
  - Notify benefits the Registrant, not the Registry or Registrar.


Similarly, the bootstrap process is likely to be further refined, if it is
not already refined thusly:

  - The DNS operator should maintain bootstrap zones for each scanning
  entity (TLD or Registrar, as appropriate)
  - Each scanning entity would then "walk" the corresponding bootstrap zone
  - The feedback between initial DS publication at the TLD parent and the
  bootstrap zone would look a lot like the mechanism used for CDS itself:
 - Publish (CDS or bootstrap)
 - Check TLD until DS is observed
 - Change/remove record (CDS or bootstrap)
  - This turns the relevant bootstrap zones into what are effectively
  FIFOs, with the scanning entity having some ability to control the size of
  the zone being scanned (by scanning more frequently)
  - Since each of the bootstrap zones are DNSSEC signed with NSEC, they
  can be very efficiently walked (this is a feature, not a bug)
  - The scanner can further be optimized into a poll-then-scan-if-needed,
  by using SOA record polling on the zone. Only scan if the poll returns a
  new SOA SN.
  - The use of Notify would be a trigger for the poll-then-scan, with the
  Notify being scoped to the bootstrap zone itself


Hopefully this fixes your cognitive issue. :-)

Brian





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





Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] scanning doesn't scale, draft-thomassen-dnsop-generalized-dns-notify and draft-ietf-dnsop-dnssec-bootstrapping

[John R Levine]

On Mon, 16 Oct 2023, Peter Thomassen wrote:

1. the parent receives an updated NS RRset,
3. the parent obtains a copy of a signaling zone and walks the signaling 
records published there (at _signal.$NS, such as 
_signal.jo.ns.cloudflare.com),


If you think about it for a moment, #3 doesn't work very well, since every 
parent needs to scan all the signalling zones for all the nameservers they 
might be using.  Cloudflare hosts at least a million zones which I'm sure 
are in every public TLD, so that means we have a thousand TLDs and/or a 
thousand registrars all scanning Cloudflare's signalling zone which is not 
going to be small.  How's that going to scale?  For that matter, how's 
Cloudflare going to give the TSIG or whatever to the thousand scanners to 
let them do it?



2. the parent chooses to do a scan,


This is no better.  For CDS scanning the scan is a single query to a 
single known server only for zones that are already signed.  But for this, 
it has to scan all the unsigned zones, and since the NS can be anywhere, 
each scan is a full recursive lookup.  That's a lot of traffic to a lot of 
servers all over the net.



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 draft is not at all concerned about how the child triggers the parent, 
but only with what the parent does *once the parent has determined* that it 
is going to attempt DS initialization.


Right.  We need to fix that gap now, when we can do it easily by updating 
the drafts in progress.  It's totally normal to have two drafts 
progressing that depend on each other.


I wouldn't forbid the other approaches but I would note that they are not 
likely to scale well to large zones like popular TLDs.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

[DNSOP] Domain provisioning template schemes?

[John R Levine]

An acquaintance wrote to me asking if there was anything to automate the kinds
of DNS stuff that hosting and mail providers need their customers to do, like
add A and  records to point to web hosts, MX and TXT for mail (the TXT is
for DKIM and SPF), and so forth, with some way for the provider to do it without
getting full access to the registrar account for the domain.

He knows about Godaddy's Domain Connect that has been around since 2015 but
hasn't gotten much traction.   Anything else?

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R. Levine]

On Mon, 17 Jul 2023, Shumon Huque wrote:

* Verifiers can't query for the specific data they need from the DNS. They
need to get a potentially large blob of data and look for what is
applicable to them by examining the rdata for each record in the RRset.
This is not a new issue. It is the well known record subtyping problem that
was advised against in RFC 5507 (IAB; "Design Choices When Expanding the
DNS"). That advice was targeted to new RR type design, but it applies just
as well to this type of use of TXT RDATA resident at the same name.


Agreed, but that horse had already left the barn when we published the 
first SPF RFC 4408.



* You can't delegate the (application specific) domain validation record to
a 3rd party.

* Even if you don't delegate the name to another party, you may have a
shared DNS zone where you need to be able to provide record level
permissions to the specific team that is responsible for the application in
question. This can't be done if all the apps share the same domain name.


Both good points, worth mentioning in the draft.

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] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

[John R Levine]

On Mon, 17 Jul 2023, Brian Dickson wrote:

The stuffed apex does not only include those tokens, e.g. SPF and friends,
which get queried A LOT.


I forgot about SPF.  Good point.


In the absence of the aforementioned draft, there is no specific guidance
that would lead ALL token issuers to use 20 character identifiers.


There's only several decades of practice and no reports of collisions, 
ever.  Remember that since it is common to publish multiple tokens for the 
same service, what everyone does is to look for the specific token they 
want and ignore everything else so even in the unlikely event that two 
people use the same tag, in practice it doesn't matter.  If you know a way 
to make 128 bit hash tokens collide, uh, some people would like to talk to 
you.


The collision argument is implausible, Just drop it and we can make the 
sensible point that you don't want to bulk up SPF responses.


R's,
John

PS: Here's that Cisco example again, sorted so you can see the multiple 
tokens per prefix.


cisco.com descriptive text "926723159-3188410"
cisco.com descriptive text "MS=ms35724259"
cisco.com descriptive text "QuoVadis=94d4ae74-ecd5-4a33-975e-a0d7f546c801"
cisco.com descriptive text "SFMC-o7HX74BQ79k7glpt_qjlF2vmZO9DpqLtYxKLwg87"
cisco.com descriptive text 
"\\200atlassian-domain-verification=blI4HshP3kJO1PV8nZFlncJ6TwVviYYxBNhkMi9wIa9DTxUjY4p1GO7O5SjiioyT"
cisco.com descriptive text 
"adobe-aem-verification=www-devint-cloud.cisco.com/24859/366173/9418f2a2-ef45-4788-9de9-91c7d19038b9"
cisco.com descriptive text 
"adobe-aem-verification=www-idev-cloud.cisco.com/24859/366204/1b990ef7-ff88-4938-bdd9-8458cc152f57"
cisco.com descriptive text 
"adobe-idp-site-verification=c900335b8b825859b51473b9943a3880ae795df47426483b0a67630377a902f5"
cisco.com descriptive text 
"amazonses:7LyiKZmpuGja4+KbA4xX3lN69yajYKLkHH4QJcWnuwo="
cisco.com descriptive text 
"amazonses:QbUv5pPHGQxRy1vKA0J7Y/biE9oR6MTxOTI1bZIfjsw="
cisco.com descriptive text 
"amazonses:mX+ylQj+fJAfh9pr03yIR7YvjKZ1bOo5ABegqM/5pvI="
cisco.com descriptive text "apple-domain-verification=qOInipPgso3W8cmK"
cisco.com descriptive text "asv=ac90e11808e87cfbf8768e69819b1aca"
cisco.com descriptive text 
"atlassian-domain-verification=2ldosmg0o2Mhpyok1OISaSGygWU9zk6fLLWdoczXtHap9luhaHA/pwEaj2Tk6ROK"
cisco.com descriptive text 
"atlassian-domain-verification=672RcADvt8BPqsb9gCN2ZC5DoTAhUT8abC1blYKQxi/MHMaGoA/BuvjFMaWRtgd7"
cisco.com descriptive text 
"atlassian-domain-verification=7JYRlY9ijBijTJ0YS5a8/58DU7OfKAHMYRufcy0TC57j2mNceH8rg4ajRzErc22Z"
cisco.com descriptive text 
"atlassian-domain-verification=AYTzL6wSVsW0IdyQp7gwv6lwtHdpMATnb8QriqyJ0niAaZct9kdSlXvfuE4GcoxU"
cisco.com descriptive text 
"atlassian-domain-verification=Gt2demeKDLmtNc9kPZhaAHFA37DEIcmFGUd6LARvB4yjLG70s3WZhaJJ15y499sb"
cisco.com descriptive text 
"atlassian-domain-verification=UwP1ncfiphlFs+wRx8wIBSXDScwNL7Jrw7tq2rnYz3+9T5+Md9eTDRgNPCikxtOx"
cisco.com descriptive text 
"c900335b8b825859b51473b9943a3880ae795df47426483b0a67630377a902f5"
cisco.com descriptive text 
"docker-verification=4c56633a-274e-4858-88a2-2aeceffcfd66"
cisco.com descriptive text "docusign=5e18de8e-36d0-4a8e-8e88-b7803423fa2f"
cisco.com descriptive text "docusign=95052c5f-a421-4594-9227-02ad2d86dfbe"
cisco.com descriptive text 
"duo_sso_verification=6Q7pJwSZ3damWHBcB8TNd9I5oduLRAFDDhip2pTFaa3QoIZtZnCgzjyZr5teSOWS"
cisco.com descriptive text 
"duo_sso_verification=AxenLdoqIXzjl2RJzE1BlOfkawDbDFlnbyvjAt8vcjKHBkvYwEMySDRk5QmBd66v"
cisco.com descriptive text 
"duo_sso_verification=IYdVUIrb2L95JVejSXV3hfsJVDZolQKKOPBztlD6TIgfCRSKeMuf8WgbQuFLD4aL"
cisco.com descriptive text 
"duo_sso_verification=pG21Oj5OPCxRPsWXsfbauWT9oua82cKtYUPAmsQvovKNq3xqWEcsEMEAhtXy8AFr"
cisco.com descriptive text 
"duo_sso_verification=sKMGaTln2vmQuKwaE4hKtTEY1UYn2JzAaxSZzGjkgJrKuZChN344mhIptyczoNBA"
cisco.com descriptive text 
"facebook-domain-verification=1zoxo8z7t013gpruxmhc8dkerq47vh"
cisco.com descriptive text 
"facebook-domain-verification=qr2nigspzrpa96j1nd9criovuuwino"
cisco.com descriptive text 
"fastly-domain-delegation-e9a758d22183504af2d5ab4d9a9853da-20210127"
cisco.com descriptive text 
"fastly-domain-delegation-im0VCGY5X0axEEmhXJb2-347911-20210310"
cisco.com descriptive text 
"fastly-domain-delegation-w049tcm0w48ds-341317-20210209"
cisco.com descriptive text 
"fastly-domain-delegation-z9slsbDdX0-368365-2021-05-14"
cisco.com descriptive text 
"google-site-verification=9MlQU9MMQ1jHLMUkONKe6QzZ-ZIGRv0BCD1_rY1Zdmc"
cisco.com descriptive text 
"google-site-verification=V3t2K3dvr9fcd1YWwwanSmebEOO_UNTP06HR2_gUO5M"
cisco.com descriptive text 
"google-site-verification=WmdDuSXl3PMb-48qcY6VUbW9kzNPe46zn9uDwgB2wX0"
cisco.com descriptive text 
"google-site-verification=lW5eqPMJI4VrLc28YW-JBkqA-FDNVnhFCXQVDvFqZTo"
cisco.com descriptive text 
"google-site-verification=qPS9ZkoQ-Og1rBrM1_N7z-tNJNy2BVxE8lw6SB2iFdk"
cisco.com descriptive text 
"google-site-verification=r-K1CIdXkgRWxZstUHtVyM2UfwflnGgr4AR9_Qhk28Q"
cisco.com descriptive text 

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

[John R Levine]

Just to be clear, I think it's quite reasonable to encourage people to put 
tokens at _name but I still see it as a matter of taste, not a technical 
issue.


On Mon, 17 Jul 2023, Brian Dickson wrote:

TCP being triggered on resolver-auth is much more of concern, particularly
when the underlying cause (large RRsets) is preventable.


I take your point, but we're not talking about a lot of traffic.  If any 
particular token is checked as often as once a day, that's a lot.  At what 
scale does the TCP traffic become an issue?



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.


The technical term would be "collision" rather than "confusion".
One harm of collision is the impact on automation. Whether at the apex or
in underscore prefixes, the collision "space" suffers from the "birthday
paradox" scaling problem.


The birthday paradox is relevant if you only have 366 birthdays, but not 
if people are using 20 character identifier strings which give you a 
10^25 point name space.  (See the Cisco TXT records in my previous 
message.)  This is an aesthetic preference, not a technical one.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

TCP, you already have worse problems, like DNSSEC doesn't work.


Triggering TCP is still not good, even if it all works. It is still
better avoiding by not stuffing the APEX. So I think we still want
to leave something in there.


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?)


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.


But people have been putting tokens at the apex for years and I have 
never, ever, heard of token confusion.  "It's ugly" isn't going to fly. I 
would take the whole thing out unless there is a technical basis I've 
missed.


$ host -t txt cisco.com
cisco.com descriptive text 
"workplace-domain-verification=Uhv7QPQ22nbuD3vG0jspf7R6LruYoS"
cisco.com descriptive text 
"google-site-verification=r-K1CIdXkgRWxZstUHtVyM2UfwflnGgr4AR9_Qhk28Q"
cisco.com descriptive text 
"google-site-verification=WmdDuSXl3PMb-48qcY6VUbW9kzNPe46zn9uDwgB2wX0"
cisco.com descriptive text 
"atlassian-domain-verification=UwP1ncfiphlFs+wRx8wIBSXDScwNL7Jrw7tq2rnYz3+9T5+Md9eTDRgNPCikxtOx"
cisco.com descriptive text 
"intercom-domain-validation=8806e2f9-7626-4d9e-ae4d-2d655028629a"
cisco.com descriptive text 
"google-site-verification=V3t2K3dvr9fcd1YWwwanSmebEOO_UNTP06HR2_gUO5M"
cisco.com descriptive text 
"google-site-verification=lW5eqPMJI4VrLc28YW-JBkqA-FDNVnhFCXQVDvFqZTo"
cisco.com descriptive text 
"atlassian-domain-verification=AYTzL6wSVsW0IdyQp7gwv6lwtHdpMATnb8QriqyJ0niAaZct9kdSlXvfuE4GcoxU"
cisco.com descriptive text 
"fastly-domain-delegation-e9a758d22183504af2d5ab4d9a9853da-20210127"
cisco.com descriptive text 
"duo_sso_verification=AxenLdoqIXzjl2RJzE1BlOfkawDbDFlnbyvjAt8vcjKHBkvYwEMySDRk5QmBd66v"
cisco.com descriptive text 
"fastly-domain-delegation-z9slsbDdX0-368365-2021-05-14"
cisco.com descriptive text 
"duo_sso_verification=sKMGaTln2vmQuKwaE4hKtTEY1UYn2JzAaxSZzGjkgJrKuZChN344mhIptyczoNBA"
cisco.com descriptive text 
"adobe-aem-verification=www-devint-cloud.cisco.com/24859/366173/9418f2a2-ef45-4788-9de9-91c7d19038b9"
cisco.com descriptive text 
"c900335b8b825859b51473b9943a3880ae795df47426483b0a67630377a902f5"
cisco.com descriptive text 
"atlassian-domain-verification=7JYRlY9ijBijTJ0YS5a8/58DU7OfKAHMYRufcy0TC57j2mNceH8rg4ajRzErc22Z"
cisco.com descriptive text 
"\\200atlassian-domain-verification=blI4HshP3kJO1PV8nZFlncJ6TwVviYYxBNhkMi9wIa9DTxUjY4p1GO7O5SjiioyT"
cisco.com descriptive text 
"mZvHszGlmDhvPOUKL+6JMiw/VtckyOMKjcw1PLcjYowxM2PVLX2xG0ZSgdHRm8HXfaaGR2pMvhIrBX1tX3aKRQ=="
cisco.com descriptive text 
"adobe-idp-site-verification=c900335b8b825859b51473b9943a3880ae795df47426483b0a67630377a902f5"
cisco.com descriptive text 
"onetrust-domain-verification=20345dd0c33946f299f14c1498b41f67"
cisco.com descriptive text 
"stripe-verification=217ec5836204d6fc0d236f5751724029c9b39530696e322a862b2f2f5fe75529"
cisco.com descriptive text 
"sending_domain731003=25e34fadea88da7e64f0fab1e32d094f1f1e0fb2b97622deac2521f7a2c5b2bc"
cisco.com descriptive text 
"atlassian-domain-verification=672RcADvt8BPqsb9gCN2ZC5DoTAhUT8abC1blYKQxi/MHMaGoA/BuvjFMaWRtgd7"
cisco.com descriptive text 
"google-site-verification=qPS9ZkoQ-Og1rBrM1_N7z-tNJNy2BVxE8lw6SB2iFdk"
cisco.com descriptive text 
"identrust_validate=ZMG4IyVxNwmt3vKpPoFmxSuWW+4fMc/M4kCCnBaPUMYv"
cisco.com descriptive text 
"atlassian-domain-verification=2ldosmg0o2Mhpyok1OISaSGygWU9zk6fLLWdoczXtHap9luhaHA/pwEaj2Tk6ROK"
cisco.com descriptive text 
"docker-verification=4c56633a-274e-4858-88a2-2aeceffcfd66"
cisco.com descriptive text "926723159-3188410"
cisco.com descriptive text 
"facebook-domain-verification=qr2nigspzrpa96j1nd9criovuuwino"
cisco.com descriptive text 
"wiz-domain-verification=af241e6396696eedf1b361891435f6b21bdebb5621941d99279298c076b5bf5f"
cisco.com descriptive text 
"duo_sso_verification=IYdVUIrb2L95JVejSXV3hfsJVDZolQKKOPBztlD6TIgfCRSKeMuf8WgbQuFLD4aL"
cisco.com descriptive text 
"duo_sso_verification=pG21Oj5OPCxRPsWXsfbauWT9oua82cKtYUPAmsQvovKNq3xqWEcsEMEAhtXy8AFr"
cisco.com descriptive text 
"adobe-aem-verification=www-idev-cloud.cisco.com/24859/366204/1b990ef7-ff88-4938-bdd9-8458cc152f57"
cisco.com descriptive text 
"miro-verification=53bf5ccd47cb6239fe5cf14c3b328050dd5679ac"
cisco.com descriptive text 
"fastly-domain-delegation-im0VCGY5X0axEEmhXJb2-347911-20210310"
cisco.com descriptive text "apple-domain-verification=qOInipPgso3W8cmK"
cisco.com descriptive text 
"facebook-domain-verification=1zoxo8z7t013gpruxmhc8dkerq47vh"
cisco.com descriptive text "v=spf1 redirect=spfa._spf.cisco.com"
cisco.com descriptive text "SFMC-o7HX74BQ79k7glpt_qjlF2vmZO9DpqLtYxKLwg87"
cisco.com descriptive text 
"amazonses:mX+ylQj+fJAfh9pr03yIR7YvjKZ1bOo5ABegqM/5pvI="
cisco.com descriptive text 
"duo_sso_verification=6Q7pJwSZ3damWHBcB8TNd9I5oduLRAFDDhip2pTFaa3QoIZtZnCgzjyZr5teSOWS"
cisco.com descriptive 

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

[John R. Levine]

The DNS people think that the network people should fix the network code 
so existing DNS resolvers work.  While the network people think the DNS 
people should fix the DNS resolvers to work with existing network code. 
Pick your poison.


By the way, it's not resolvers that need IPv4 literals.  It's any 
application that connects to IPv4 addresses that are either built into the 
code or found through a config or lookup, often not the DNS.  I can't tell 
you how common that is, but it's not as rare as you mght hope.  I also 
couldn't tell you the relative difficulty of writing shims and putting 
them around connect to an IPv4 address or around DNSSEC validation.


R's,
John

On Sun, 9 Jul 2023, Momoka Yamamoto wrote:


Dear All,

Thank you for your constructive feedback and the rich discussion that has
followed the sharing of the draft. I've taken the time to digest all your
comments.

Concerning the DNS64 breaking DNSSEC issue:
As Philip rightfully pointed out, the inclusion of DNS64 in this draft has
indeed been misleading, and I will amend it by removing references to
DNS64. DNSSEC is an important topic but this proposal doesn't directly
interact with DNS64, hence the DNSSEC issues associated with DNS64 are out
of its scope.

Regarding the specificity of DNS resolvers when RFC7051 exists, there is a
diverse range of opinions on this topic on list, some arguing the necessity
of such documentation and others deeming it redundant. Some considerations
I think are important include:
* A resolver is one of the few applications that have a genuine requirement
to use an IPv4 literal.
* The inability of an iterative resolver to utilize RFC7050 for Pref64
discovery may be worth highlighting.
* While 464XLAT has demonstrated its effectiveness in home networks
supporting various apps and devices, the situation is different for DNS
servers with more uniform tasks. In these cases, executing the translation
within the resolver software could be more efficient.
The process of the iterative resolver creating an IPv4 socket, which is
then translated to an IPv6 packet by the CLAT, is inefficient as it adds an
unnecessary layer of packet translation.
* However, considering instances like Thread and other applications such as
browsers, which already implement the synthesizing function, a draft
dedicated to iterative resolvers may seem repetitive.

Concerning the appropriate Working Group for this draft:
While there is ongoing debate about whether this draft should be adopted or
not, I did not find any strong opinions stating that this draft should be
conducted at DNSOP.
Furthermore, as Med proposed, BCP 91 could be updated, 19 years
post-publication, to include these solutions for IPv6-only networks.

For a more comprehensive and balanced draft, future steps will include
removing references to DNS64 and incorporating both the 464XLAT and Pref64
solutions.
For those unable to transition to 464XLAT promptly, having the resolver
execute the translation will act as an essential bridge. This, however,
does not preclude the consideration of 464XLAT as a potential future
strategy.
This approach aims to provide well-rounded guidance, assisting in better
decision-making.

I look forward to further discussions and appreciate your feedback on these
matters.

Best Regards,

Momoka Y



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] draft-dulaunoy-dnsop-passive-dns-cof

[John R Levine]

On Thu, 29 Jun 2023, Ben Schwartz wrote:

If you're running 8.8.8.8 your logs have a whole lot of PII, but if you're
running resolvers in front of industrial networks and using PDNS to look
for malfunctioning or compromised IoT boxes, there's no PII at all.

Yes, but since the format doesn’t carry client IPs, it’s not very friendly for 
this IoT use case.  We could fix that!


PS: I would want to ask the people who use it whether they'd find an 
optional client IP field useful.  If so, sure.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

If the IETF says “deidentified DNS logs are basically anonymous” vs. 
“deidentified DNS logs are basically PII”, I believe that makes a big 
difference in the world.  Expert practitioners might already understand the 
nuance here, but our audience is broader than that.


But neither is consistently true.  If there's PII in the underlying data, 
then there is a risk (I honestly don't know how much) of recovering that. 
If it's a bunch of machine tools and themocouples, there isn't.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

When the IETF documents something, that is unavoidably an endorsement.  We 
should be cautious about what we endorse.


To some degree, but when we imagine that not documenting something that 
already exists will make people stop doing it, we just confirm the 
impression that we and our standards are out of touch with the real world.


In this case, the risks may be less obvious, and we should work to make 
them more obvious.  For example, we could decide to add a mandatory 
client IP field.  This would help to emphasize that the data is in fact 
highly sensitive, and must be treated with the same level of caution as 
other PII logs.


We could, and all the passive DNS operators who have already implemented 
this decade old draft will roll their eyes and continue doing what they 
have been doing.  That is an excellent example of what *not* to do.


If you're running 8.8.8.8 your logs have a whole lot of PII, but if you're 
running resolvers in front of industrial networks and using PDNS to look 
for malfunctioning or compromised IoT boxes, there's no PII at all. 
Everything we build is at least dual use, and we are not very good at 
guessing how people will use them.



As it stands, I think this format is something of a privacy footgun.  It looks 
reasonably deidentified, but in the DPRIVE threat model (see e.g. RFC 7626) it 
is highly reidentifiable.


I completely agree that we need to document the security and privacy 
issues and suggest ways both to understand what they are, and how to 
mitigate them.  But if we imagine that we are smarter than the people who 
use our specs, well, we aren't.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
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 R Levine]

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. ...



Well, OK, you do that, half the emails bounce, half of what's delivered is 
reported as spam, and the third half are ignored.  Now what?


In practice it isn’t quite as bad as that.  Require registrars to refuse
renewals until the issues are addressed.


Please see "signficant operational change" above.

My feeling is that if it's not important enough for *you* to have your DNS 
working, it's not important for *me* either.  I'm happy to help people who 
are having trouble fixing problems, but not to waste time on people who 
don't care.


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 R Levine]

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.


No, it is not a “significant” change.  It should just be a minor extension
of the existing requirement to keep the NS and glue records consistent.

Even if it was you just introduce it with a soft start.  Just start checking
the delegations of every TLD like zone then report the broken servers
publicly and email the contacts for the delegation.  The tools for checking
already exist.


Well, OK, you do that, half the emails bounce, half of what's delivered is 
reported as spam, and the third half are ignored.  Now what?


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

On Thu, 27 Apr 2023, Miek Gieben wrote:
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.


I looked into this for https://github.com/miekg/dns

The option is trivial to implemented (in an auth server). I.e. seems similar 
to NSID.


I agree that it's not hard to do.  But the Camel reminds us that there is 
an unlimited number of hacks that would be easy to implement, but not 
necessarily that anyone would use.  Hence my question about whether 
anyone's implemented it.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] Updated: Compact Denial of Existence

[John R Levine]

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?


Because a bazillion existing clients expect to find it there.

I think we are talking past each other.  If you're saying this approach is 
better than black lies, I agree it is, but we would never standardize 
black lies because it returns wrong results.


I think this rather hacky approach could work: a client sends a request 
with the compact denial flag.  The upstream does whatever it does and gets 
a result.  If the result is anything other than an NXNAME, return the 
result and cache it normally.  If it's a NXNAME, return the result, but 
put it in a special cache that only returns results to subsequent queries 
with the compact denial flag set, since they're the only ones that know 
what NXNAME means.  You might have the same result cached with a NXNAME 
for compact denial clients and a white lie for other clients, but so be 
it.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] Updated: Compact Denial of Existence

[John R Levine]

John it won’t work with chained validators.


How about if I only send a "lie to me" option upstream if I get one from 
my client?  I realize this means takeup will be pretty slow.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

On Fri, 19 Aug 2022, Stephen Farrell wrote:

domains at IANA.


FWIW, that doesn't describe where I've so far
landed on this. It omits the requirement that
there be an RFC for each entry.


As I've said several times, most recently yesterday, if we make people 
jump through hoops to put their names on the list, most quasi-DNS will 
continue to ignore us and squat wherever they are squatting now.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

I could have been clearer.  The names can be duplicates, not the rest of the 
entry.  So someone comes along and registers web.alt with a pointer to her 
thing, then someone else comes along with a different thing but also calls it 
web.alt, and we another entry in the registry.


What does the registry do or prevent? Is it meant to be a Yellow Pages of 
non-IETF naming ? If so, why should we run it? If it accomplishes something 
else, what ?


If people want to avoid collisions, it gives them an idea of what's 
already in use somewhere.  Of if you run into ITU.ALT, you can (give or 
take link rot) find out what it is supposed to do.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

On Thu, 18 Aug 2022, Paul Wouters wrote:

On Aug 18, 2022, at 18:30, John Levine  wrote:


It appears that Eliot Lear  
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


This is incorrect. A nunber of them got together to do them bundled in one RFC 
and were told to split it up. At least two of them did.


You're right but it's still a tiny handful of all of the alt roots and 
namecoins and all the other stuff that is supposed to make the DNS 
obsolete.


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.



Can you explain the difference between the first come and the second come ?  If 
there is no difference, it’s not FCFS. If there is a difference, it’s not 
really a duplicate.


I could have been clearer.  The names can be duplicates, not the rest of 
the entry.  So someone comes along and registers web.alt with a pointer to 
her thing, then someone else comes along with a different thing but also 
calls it web.alt, and we another entry in the registry.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

I agree with this for TLD strings but the special use domain names registry is 
also used for registrations under .arpa which we want to keep. Is there an RFC 
other than 6761 that would cover those ? Eg currently resolver.arpa is going 
through 6761.


Good point.  Leaving it open for .arpa subdomains is fine, keeping in mind 
that names in .arpa are managed under RFC 3172, not 6761.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

That said, I believe what Warren is suggesting is more of a ten thousand foot 
view of the namespaces issue; and if that finds a way to allow innovation 
without fragmentation, it would be beneficial for DNS and non-DNS names alike.


That would be swell, but since we've been wrestling with this problem for 
25 years and have made no progress, I don't think a few more rounds is 
likely to provide a breakthrough.


It's not a technical problem, it's a social or political one.  People have 
projects outside the DNS and want to name them with DNS names.  Sometimes 
you can't have what you want.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7064)

[John R. Levine]

I don't recall that anyone judged it incorrect.  I think we just made a 
clerical error. 


absent a recollection -- or documentation -- the proffered assessment lacks a 
basis.


I don't recall documentation or even recollection of why those entries 
changed from one draft to the next.  I do recall a great deal of editing 
of that table, including taking out a lot of second level tags that didn't 
belong in it,


In any event, the underlying references make it quite clear why 
Bernie's fixes are the right ones.


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] [Editorial Errata Reported] RFC8552 (7064)

[John R. Levine]

So, for example, why is this latest reference correct this time, when it was 
judged incorrect, the last time is was used for the entry?


I don't recall that anyone judged it incorrect.  I think we just made a 
clerical error.


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] [Editorial Errata Reported] RFC8552 (7064)

[John R. Levine]

So, just to be clear, I'm approving all of these errata, yes?


That's what I'd do.



On Wed, Aug 03, 2022 at 6:38 PM, John R. Levine  wrote:


On Wed, 3 Aug 2022, Dave Crocker wrote:

Original Text
-
| URI | _acct | [RFC6118] |

Corrected Text
--
| URI | _acct | [RFC7566] |

In Spring, 2018 and again in Fall, 2018, there was some focused discussion
(see:  dnsop) about _acct, and related strings, and which citation to use
for the enum-related values.  The choice bounced around, as I've cited.
This includes having what is now being deemed the 'correct' choice in
-14...

Note that none of the cited documents refers to the exact string "_acct".
So there is a derivation process that seems to be unclear. I believe the
attrleaf RFC contains no pedagogy about this, but it probably should.

I remember the rather long discussions about the possible collisions in
URI names between transport and enumservice names, and again about whose
job it is to keep registries in sync. Bu in this case we made a clerical
mistake, and missed the important detail that after the enumservices update
in RFC 6118, some of the types were added in later RFCs.

Having looked at all of Bernie's errata, I don't think any of them present
subtle errors. There was an eye-glazing list of entries in that document
and we unsurprisingly missed a few details.

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





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] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

[John R Levine]

It is not a viable choice outside of a few nerds who are fully capable of 
getting a browser plug-in to handle gns:// URIs. Which would still allow all 
DNS parsing libraries to be used on the names.


Sufficiently motivated people seem able to install whatever it is you need 
to browse through Tor.  I wouldn't think a GNS resolver would be much 
harder.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7064)

[John R. Levine]

On Wed, 3 Aug 2022, Dave Crocker wrote:

Original Text
-
  | URI| _acct | [RFC6118] |

Corrected Text
--
  | URI| _acct | [RFC7566] |


In Spring, 2018 and again in Fall, 2018, there was some focused discussion 
(see:  dnsop) about _acct, and related strings, and which citation to use for 
the enum-related values.  The choice bounced around, as I've cited.  This 
includes having what is now being deemed the 'correct' choice in -14...


Note that none of the cited documents refers to the exact string "_acct".  So 
there is a derivation process that seems to be unclear. I believe the 
attrleaf RFC contains no pedagogy about this, but it probably should.


I remember the rather long discussions about the possible collisions in 
URI names between transport and enumservice names, and again about whose 
job it is to keep registries in sync.  Bu in this case we made a clerical 
mistake, and missed the important detail that after the enumservices 
update in RFC 6118, some of the types were added in later RFCs.


Having looked at all of Bernie's errata, I don't think any of them present 
subtle errors.  There was an eye-glazing list of entries in that document 
and we unsurprisingly missed a few details.


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] [Editorial Errata Reported] RFC8552 (7068)

[John R. Levine]

Again RFC 7553 since they're transportts.


The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7068

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.1.2.

Original Text
-
 | URI| _tcp  | [RFC6118] |
 | URI| _udp  | [RFC6118] |

Corrected Text
--
?

Notes
-
Wrong reference. RFC6118 does not even mention "tcp" nor "udp". Unaware of 
useful reference(s). Not sure this line needs to be removed.

Note that this also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG




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] [Editorial Errata Reported] RFC8552 (7065)

[John R. Levine]

This looks correct, too.

On Tue, 2 Aug 2022, RFC Errata System wrote:


The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7065

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.2.1

Original Text
-
 | URI| _iax  | [RFC6118] |

Corrected Text
--
 | URI| _iax  | [RFC6315] |

Notes
-
Wrong reference. Note that is also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG




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] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

[John R. Levine]

On Tue, Aug 02, 2022 at 07:11:38PM +, Paul Hoffman wrote:


recommends that the ICANN board to pick a string that will never be put 
into the DNS root, and thus is usable for systems like GNS.


This was, of course, the whole point of the .alt draft in the first place, at 
least when I was involved in preparing it.


Indeed.  If you look at SAC113 and draft-ietf-dns-alt-tld, you'll see a 
lot of the same names.


 I don't think any of us involved then cared whether it was alt or one 
of thousands of other strings that it could have been.


The leadning candidates were .ALT or one of the ISO 3166 User-assigned 
codes like .QZ, but I agree that picking one is more important than which 
one gets picked.


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] [Editorial Errata Reported] RFC8552 (7067)

[John R. Levine]

This should also be RFC 7553 since SCTP is a transport.

On Tue, 2 Aug 2022, RFC Errata System wrote:


The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7067

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.1.2.

Original Text
-
 | URI| _sctp | [RFC6118] |

Corrected Text
--
?

Notes
-
Wrong reference. RFC6118 does not even mention "sctp". Unaware of a useful 
reference. Not sure this line needs to be removed.

Note that this also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG




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] [Editorial Errata Reported] RFC8552 (7065)

[John R. Levine]

This also looke correct.

On Tue, 2 Aug 2022, RFC Errata System wrote:


The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7065

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.2.1

Original Text
-
 | URI| _iax  | [RFC6118] |

Corrected Text
--
 | URI| _iax  | [RFC6315] |

Notes
-
Wrong reference. Note that is also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG




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] [Editorial Errata Reported] RFC8552 (7066)

[John R. Levine]

I believe the correct reference is RFC 7553, where section 4.1 says the 
name of a URI record is _service._transport, just like SRV, and DCCP is a 
transport.


On Tue, 2 Aug 2022, RFC Errata System wrote:


The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7066

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.1.2.

Original Text
-
 | URI| _dccp | [RFC7566] |

Corrected Text
--
?

Notes
-
Wrong reference. RFC7566 does not even mention "dccp". Unaware of a useful 
reference. Not sure this line needs to be removed.

Note that this also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG




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] [Editorial Errata Reported] RFC8552 (7064)

[John R. Levine]

This looks correct to me.


The following errata report has been submitted for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of 
Attribute Leaves".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7064

--
Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.1.2.

Original Text
-
| URI| _acct | [RFC6118] |

Corrected Text
--
| URI| _acct | [RFC7566] |

Notes
-
Wrong reference. Note that is also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8552 (draft-ietf-dnsop-attrleaf-16)
--
Title   : Scoped Interpretation of DNS Resource Records through 
"Underscored" Naming of Attribute Leaves
Publication Date: March 2019
Author(s)   : D. Crocker
Category: BEST CURRENT PRACTICE
Source  : Domain Name System Operations
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG




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] Call for Adoption: Survey of Domain Verification Techniques using DNS

[John R. Levine]

Alternately, mostly deleting section 3 (the survey part), renaming the 
document and focusing on section 4 (the recommendations part) might be 
worthwhile, but that section is all about formatting TXT messages in a 
specific way and that's generally been considered anathema for DNS for oh so 
many reasons.  So that may also not be a correct approach.


That ship sailed a long time ago with the failure of the SPF record. 
People use TXT records for one-off things and they're not going to stop.


I agree that the list of implementations should be deleted or summarized 
in an appendix.


What might be useful is a shorter recommendation section with no MUST 
stuff, since it's not standards track, saying something like:


If you use a TXT record, use a _prefix ond register it in the IANA prefix 
registry.  Use a fixed descriptive initial part in the text string so you 
don't get faked out by wildcards.  Do not add more junk to the TXT records 
in the domain itself.


If you use a CNAME record, use either a registered _prefix, or a 
pseudo-random prefix.


R's,
John

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

[DNSOP] Wildcard junk vs NXDOMAIN junk

[John R. Levine]

A friend of mine asserts that wildcard DNS records are a problem because 
hostile clients can use them to fill up DNS caches with junk answers to 
random queries that match a wildcard.  But it seems to me that you can do 
it just as well with random queries that match nothing and fill up the 
cache with NXDOMAIN junk answers.  Am I missing something here?


If you add DNSSEC, with or without RFC 8198 response synthesis, the 
details change but I don't think answer does, it's about the same either 
way.


I can see attacks where you might use URLs with wildcard names to fill web 
caches with junk pages (see https://www.web.sp.am/) but that's different.


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] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)

[John R. Levine]

 5.  Authoritative DNS Servers: Authoritative servers MUST respond to
 queries for .onion with NXDOMAIN.


I think this text is correct.

The whole point of .onion and other special use domain names is that they 
are resolved outside of the DNS.  RFC 6761 says they should be caught at 
a recursive server if not earlier.


If a query for a special use name, whether it's foo.onion or 
7.8.9.10.in-addr.arpa, leaks to an authoritative server, NXDOMAIN is the 
right answer.


R's,
John


Corrected Text
--
 5.  Authoritative DNS Servers: Authoritative servers MUST respond 
non-authoritatively to
 queries for names in .onion.
The original text for 5 and 6 is conflicting. A name server cannot respond with 
NXDOMAIN (which is an authoritative answer) without having a zone configured to 
serve that NXDOMAIN from. Clearly the intent of the text is that clients will 
not find authoritative answers to .onion queries anywhere in the DNS.


The corrected text does not describe what to return though. I guess the
text implies REFUSED, but perhaps the WG reasoned this was not good as
it would lead to more queries to other servers or instances of the
authoritative server set?


Yes, it implies REFUSED. I was unsure REFUSED was standardised, or
whether it is still a convention that almost all auths happen to
follow. REFUSED would indeed lead to resolvers trying other auths
(although that seems a bit theoretical - where did the resolver even
come up with the idea to ask a bunch of auths about .onion names?).

I also now realise that the root servers do not honour my new text, and
their behaviour -is- correct, so perhaps:

5. Authoritative DNS Servers: Authoritative servers (other than the
root servers) MUST respond non-authoritatively to queries for names in
.onion.


Yes, the root servers respond with an authoritative name error for QNAMEs under 
.ONION. For them to do otherwise would arguably break the commitment they have 
made many times to serve precisely the root zone provided to them by the IANA.

I do see the problem that the proposed erratum is trying to address. However, I 
don't see much difference between clients of a resolver receiving a 
non-authoritative name error (e.g. a negative response from a root server that 
has been cached) vs. an authoritative name error (e.g. a negative response from 
a resolver that has been configured to answer in such a fashion). And I don't 
really see the point in any RFC suggesting that they can MUST operators into 
acting in any particular way, regardless of whether the servers they administer 
are acting as recursive or authoritative.

The idea of modifying the protocol to accommodate namespaces outside the DNS is 
causing me to throw up in my mouth a bit, to be honest. Perhaps the DNS could 
just concentrate on being the DNS and other namespaces can fight their own 
battles?


Joe


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] DS glue for NS draft

[John R Levine]

On Fri, 13 Aug 2021, Ben Schwartz wrote:

I think we can summarize the recent DS-glue-signing drafts as follows:

* draft-fujiwara-dnsop-delegation-information-signer: One new DS holding a
hash of all the glue records.
* draft-dickson-dnsop-ds-hack: Each new DS holds the hash of one glue RRSet
* draft-schwartz-ds-glue: Each new DS holds one glue record verbatim


Thanks, this is very useful.

FWIW, 
https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-01#section-3.2 says


  Source Records reconstructed from DSGLUE SHOULD be processed exactly
  like ordinary unauthenticated glue records.  For example, they MAY be
  cached for use in future delegations but MUST NOT be returned in any
  responses (c.f.  Section 5.4.1 of [RFC2181]).


I get that, but it still seems odd to have signed-but-not-authoritative in 
between unsigned and signed. If you're not supposed to treat them as any 
more credible than unsigned glue, what's the point of signing them?


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

On Thu, 29 Jul 2021, Jared Mauch wrote:

I think calling out that it’s possible people will create situations where a 
name won’t resolve, is similar to what happens with routing that isn’t 
deterministic as well.  We should be defining how to determinsticly resolve a 
name and highlight that it’s flexible enough you can configure it so it won’t 
work.


Sounds reasonable.  I'd also like us to keep in mind what our capitalized 
words mean.  MUST means "do this to interoperate".  The only MUST I've 
seen in this document is that servers MUST return all in-bailiwick glue.


I don't think there's anything harmful about returning sibling glue, but 
it is 100% optional. Ignoring NS loops, anything you can get with sibling 
glue you can get by another query, which makes it a MAY.  Maybe two 
queries are slower, maybe the single response with extra glue needed a 
retry with TCP while the two simpler responses could each use UDP, so 
maybe not.


Conflating it with in-bailiwick glue is 100% confusing, which I why I 
think we should drop it and stick to the important point about all the 
in-bailiwick glue.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John R Levine]

We are clearly talking past each other here.  Let's see what the rest of 
the WG thinks.


I think we need to think harder about "what is required for the DNS 
protocol to work" vs "what do I think might be a nice idea."


R's,
John

On Wed, 28 Jul 2021, Shumon Huque wrote:


On Wed, Jul 28, 2021 at 12:20 PM John R Levine  wrote:


On Wed, 28 Jul 2021, Shumon Huque wrote:

Sibling glue was already covered in RFC 1034 (even though there was no

term

for it). ...


Sure, but we've been cleaning up the ambiguities and errors in 1034 for 30
years.  A straightforward reading of that paragraph also gives you the
Kaminsky attack.



The Kaminsky attack can redirect in-bailiwick nameserver names just as
easily as out-of-bailiwick. The defenses against it are (1) make it harder
(source port randomization etc), or (2) deploy DNSSEC. Glue is
unauthenticated
anyway, so the only real defense against misdirection is DNSSEC and
a secure referral to the child.

Also, sibling glue is easier to accept for a paranoid resolver. It may not
be in-bailiwick (i.e. a subdomain) of the "delegated zone", but it is in-
bailiwick of the "delegating zone". If a paranoid resolver, ignores and
re-queries for the sibling names, it ends up requerying the same authority
and then getting a response with in-bailiwick glue. So, it just did a bunch
of additional work for not much benefit in my opinion.

But this is an interesting topic. What do resolver implementations do
when presented with sibling glue? Can implementers comment? I think
this can help inform what we recommend in the draft.

"MUST" in RFC-ese means you have to do something in order to interoperate.

I think we all agree that the DNS will operate fine without sibling glue,
other than NS loops which I personally don't care about. That makes it at
most a MAY, and I agree with Geoff's reasons to take it out completely.



I don't agree we should take it out, since as I pointed out, RFC 1034
explicitly
covers this type of glue (without giving it a name), and the algorithm will
include it if it is there. If there is a compelling security or other
reason to
remove that, someone should make that case (I haven't heard it yet).

But it seems we will not get consensus on truncating if sibling glue doesn't
fit, so I'm okay with relaxing that requirement.

Shumon.



Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

On Wed, 28 Jul 2021, Shumon Huque wrote:

Sibling glue was already covered in RFC 1034 (even though there was no term
for it). ...


Sure, but we've been cleaning up the ambiguities and errors in 1034 for 30 
years.  A straightforward reading of that paragraph also gives you the 
Kaminsky attack.


The simplest way to defend agaist cache poisoning is to accept only 
in-bailiwick glue which you can do with a string comparison.  If you're 
going to accept sibling glue, now you have to look up the tree and see if 
both names have the same parent.  That's not all that hard, but it's a big 
step up in implementation complexity from the string comparison.


How about this?

 foo.test NS abc.def.bar.test
 abc.def.bar.test A 10.11.12.13

but there's a zone cut at def.bar.test.  Is a nephew* still a sibling? 
What if that zone cut is in the PSL?  I have no idea and I don't think I 
want to find out.


"MUST" in RFC-ese means you have to do something in order to interoperate. 
I think we all agree that the DNS will operate fine without sibling glue, 
other than NS loops which I personally don't care about. That makes it at 
most a MAY, and I agree with Geoff's reasons to take it out completely.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

* - I don't know of an English word that means niece-or-nephew

___
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 R Levine]

take the following delegations in the parent zone example.

foo.example NS ns.bar.example
ns.foo.example  2001:0DB8::000b::1

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


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.


It's kinder to make stuff just fail so people fix it than to make it 
sometiemes work, depending on what version of what software people's 
multicasted queries happen to land on.


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 R Levine]

Just to make sure we're talking about the same thing, the definition of
sibling glue is glue from another zone delegated from the same parent.


That's not what the example in 4.1 of the draft shows.  It has foo.test
depending on ns1.bar.test, so the server adds the A record for
ns1.bar.test.


It does actually.


Oh, sorry, I misread your message.


"ns1.bar.test/A" is glue for "bar.test" (and sibling glue for "foo.test" in that
example). It is returned by the servers for "test" in a referral for "foo.test".

Open to suggestions for more clarifying language.


Unless I'm misunderstanding something, in the absence of sibling glue, the 
resolver would make a second request for ns1.bar.test, same as if it were 
ns1.bar.otherdomain, and it would get back a referral with the glue.  It 
is just a performance tweak and I don't see why we should describe it as 
more than that.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

We say that authoritative servers MUST return all the glue, which is true
for real glue, but not true for sibling glue (unless the sibling is in
a loop which is not something to encourage.)  Let's not confuse people, please.


Just to make sure we're talking about the same thing, the definition of
sibling glue is glue from another zone delegated from the same parent.


That's not what the example in 4.1 of the draft shows.  It has foo.test 
depending on ns1.bar.test, so the server adds the A record for 
ns1.bar.test.


If we can't even agree what sibling glue is, perhaps we should snip it out.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-13.txt

[John R Levine]

I'd also like it to say more clearly up front that .ALT is for names that are
totally outside the DNS protocols, not for names handled locally using DNS 
protocols.
It's for things like .onion, not like .local.


Both .onion and .local use protocols other than the DNS, acknowledging of 
course that the protocol used for names under .local is quite DNS-like.


My wording wasn't great -- .local resolves to an IP address while .alt 
doesn't.


Did I miss the conversation where the working group decided to pivot? 
(Not a rhetorical question! I am very prepared for the answer to be yes 
:-) If anybody has a handy pointer to the relevant part of the mailing 
list archive I'd appreciate it.


If you mean draft-arends-private-use-tld, that was tilting at a different 
windmill.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-13.txt

[John R Levine]

Unfortunately, having multiple resolution systems using the same
namespace and syntax does not provide a signal to denote which
resolution mechanism should be used - clearly .com is "in the DNS" and
.onion isn't -- but this doesn't scale, and simply saying "the DNS is
the only resolution system" doesn't either


It would have been nice if ToR used onion://drugmart rather than 
http://drugmart.onion, but we lost that fight a long time ago.


I have occasionally wondered whether we could define an agreed set of 
levels for DNS-ish name semantics, e.g.:


* application data stream (onion)

* resolve to a perhaps nonroutable IP address that can connect to 
a data stream (various LAN level proxy hacks)


* resove to an IP address that acts like a real IP address (most DNS 
resolution behind a NAT)


* resolve to a real IP address (DNS resolution without a NAT)

These are just examples, please consdider the overall idea, not the color 
of the bikeshed.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[John R Levine]

Pushing text processing onto the client does not reduce the complexity; it
just moves it to people who are less likely to be reading DNSOP.  Notably,
it moves that responsibility to a place where typical text processing
errors are far more dangerous, and malicious inputs are far more likely.


I suppose, but it also moves it to people who are more likely to care.

I don't know if you've looked at the state of DNS provisioning software, 
but it is pretty bad.  While I'm sure that bind and nsd and powerdns can 
handle anything, I', also sure that approximately nobody outside of a few 
large sophisticated sites will use SVCB because their local DNS 
provisioning crudware doesn't support it.  If you can say it's easy, it's 
a couple of numbers and strings, they might.  If they have to parse and 
sort and dedup and look up code numbers, uh, sure, maybe later.  Much, 
much, later.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[John R Levine]

On Thu, 13 May 2021, Ben Schwartz wrote:

SVCB's key=value zone-file format is borrowed straight from DNS-SD (RFC
6763); it is not new to DNS users.


Hey, wait a minute.  DNS-SD just sticks the "key=value" strings as-is into 
text fields.  Now that I look closer, I see what Brian's objection is and 
I have a lot more sympathy for it.


No other RRTYPE has master file processing anywhere near as complicated as 
this:


~>  - sort the SvcParams by key

 - verify their uniqueness
 - deal with list of fields nested in other fields (this includes the
discussed comma escaping)~


If you put the SvcParams into text strings and let the client sort it out, 
I think the objections would go away.  This would mean that there could be 
zone files with semantically invalid SVCB records, yes, but that's nothing 
new, and the client has to check for that anyway.


Look at NAPTR.  It has a reputation for being very complicated but the DNS 
part is trivial, just a few numbers and strings.  The heavy lifting of 
regular expression matching all happens in the client.  If someone 
publishes a NAPTR with an invalid regexp, that's not the master file or 
server's problem.  It's something to catch at a higher level.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[John R Levine]

(The history of SMTP is, I think, a good poster child for this, with MX,
A, , plus DNSSEC and TLSA support in the clients, which are email
transport things, not merely DNS things.)


Not really.  MX and A mean different things, and it is useful and common 
for an SMTP server to be pointed to via MX and A with different names.



The SVCB parameters' wire format is an extremely simple TLV arrangement; I
don't think "a complex parser" is required.  It's also far from a novel
design for DNS; in fact, it's identical to the widely implemented OPT RR
RDATA format from 1999 [1][2].


Having written some DNS parsers, I agree.  Parsing the fields out of the 
wire format is easy.  I have reservations about SVCB but the encoding 
is not one of them.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] broken compressed names, was A draft about the Name:Wreck problem draft-dashevskyi-dnsrr-antipatterns

[John R Levine]

On Thu, 15 Apr 2021, Christian Huitema wrote:

Adding test vectors would help, especially broken vectors.


+1. That would be a pretty good way for the IETF to help clean the mess. 
That, and maybe a DNS site that would serve the test vectors.


In this case I think it's a reasonable idea but I echo jck's concern that 
test vectors can turn into de-facto standards, particularly when the tests 
and the text turn out not to exactly match.


On the other hand, is it valid for a DNS compression pointer to point 
forward in the message?  Why or why not?


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] NXDOMAIN and RFC 8020

[John R Levine]

On Tue, 6 Apr 2021, Andrew Sullivan wrote:
In a somewhat different world where we used RRTYPEs rather than _tag names, 
we could do tree walks a lot more efficiently.


I guess we're now in the world-record running for "somewhat" doing the most 
amount of work in a sentence?  


Hey, I'm the guy who wrote the DNS extension language so the web crudware 
that manages your DNS can automatically handle new RRTYPEs.  It's even 
part of perl's Net::DNS but it otherwise hasn't caught on.  Bummer.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] NXDOMAIN and RFC 8020

[John R Levine]

_dmarc.newjersey.sales.bigcorp.wtf
_dmarc.sales.bigcorp.wtf
_dmarc.bigcorp.wtf



Sure, but if I query "_dmarc.newjersey.sales.bigcorp.wtf" and I get back an
NXDOMAIN for "sales.bigcorp.wtf", I can eliminate at least one query,


But you won't, you'll get back an answer for the name you looked up.

You could do a seprate check first for sales.bigcorp.wtf but as I said I 
don't think that will usually win.  It is my impression that the domain 
name tree is pretty flat, and if you limited a tree walk to four or five 
levels, that would catch every real DMARC record.


Also, if your DNS cache is synthesizing NXDOMAIN results either under a 
higher NXDOMAIN (RFC 8020) or using DNSSEC (RFC 8198) those queries will 
be pretty cheap to haandle since they won't cause any upstream queries, so 
you might as well just do the tree walk.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] draft-ietf-dnsop-delegation-only is still not useful

[John R Levine]

A solution was given for moving signed glue to its own sub zone. I understand
you don't think that solution works for you. That is fine.


But that makes the false assumptions that there is a problem to be solved, 
and that glue is the only thing other than NS found in TLD zones.



I think there could be TLDs and SLDs that want to deploy this single > bit.


Could you identify the TLDs, please?  The TLDs I have talked to have 
shown no interest at all in this hack.



If you want to stop wasting time, you could just let those who want
it have the code point.


Um, I am pretty sure I am not the code point police.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] Tell me about tree walks

[John R Levine]

On Sun, 22 Nov 2020, Stephane Bortzmeyer wrote:

IMHO, the CAA algorithm is bad because it crosses administrative
boundaries. RFC 8659 at least excludes the root but it still allows,
for instance, AFNIC to put a CAA record in .fr which will apply to all
.fr domains which do not have an explicit CAA. It seems bad.


I don't see why, since it only acts as a default.  Any registrant that 
cares which CA they use can publish their own CAA.  If the registrants 
object, that's between them and Afnic.


Over in DMARC land we have a proposal called PSD which specifically sets 
a default policy for the whole TLD, since .BANK and .INSURANCE want to do 
that for their registrants.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] Tell me about tree walks

[John R Levine]

I understand the reason why being able to identify the registrar for a
particular domain is useful (or "necessary" depending on your perspective).
I don't understand the overlap between this problem and the problem that
John is trying to solve, though. Could you explain?


i'm happy to try. otherwise i'll just be sheltering in place.


I read all your stuff and it's clear to me that it has nothing to do with 
my question about DNS tree walks.


R's,
John

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

Re: [DNSOP] Tell me about tree walks

[John R Levine]

if you guys are going to automate and secure the public suffix list
functionality, ...


Not a chance.


seems like we're passing like ships in the night here.


We had a DBOUND working group that tried and failed to do that.  For 
DMARC, we don't really care where the boundaries are, only if someone up 
the tree has a default policy.



i know about the business plans. so icann will never require it. but if
there's an ietf specified way for a registrar to signal their role in all
their domains, it'll be seen by at least one of them as a market
differentiator. (i know the ones i'll be proposing this to.)


Um, perhaps talk to them and let us know what they say?  The registrars I 
know are all using GDPR are an excuse to publish nothing at all.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] Tell me about tree walks

[John R Levine]

if you guys are going to automate and secure the public suffix list
functionality, ...


Not a chance.


icann will likely never require it, but hopefully ietf can specify
it, after which the invisible hand of the market can decide it.


Doubly not a chance.  Having been hanging around the "expedited" process 
at ICANN I can assure you that the registries will voluntarily provide no 
WHOIS data at all.  The business plan, you know.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] Tell me about tree walks

[John R Levine]

It occurs to me that for DMARC's purposes, walking up the tree would
work better than the current hack.



CAA records are perhaps less of a target for query amplification abuse
than DMARC records :-)


I dunno, seems to me the stakes are higher for CAA but the number of 
requests per domain are far lower.



One possible way for DMARC to mitigate it would be to walk *down* instead
of up, and (in the application, not relying on the recursive server) stop
on NXDOMAIN because RFC 8020 tells you this is sensible, otherwise take
the last result you find.


I wouldn't want to skip the cache.  In most settings there's a whole lot 
of mail from the same place and most of the answers are likely to be 
cached.  Perhaps just note that if you're worried about this, use a cache 
the does RFC 8020.


There's also the practical fact that the amount of real mail from domains 
with more than 5 or 6 labels rounds to zero and you could limit the tree 
walk to 10 labels without losing anything.  If there's no DMARC record at 
the name itself, and you walk up 10 labels without finding anything, 
pretend you found one says to reject everything.  People who really REALLY 
want 37 label names need to put DMARC records every 10 levels.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

[John R Levine]

If there are RRSIG(A) records in .com and .net there must have been a
policy change since 2010?


Sorry, no, they're different.  For all of the new TLDs they run they have some 
test
delegations with name servers in the TLD:

emt-ns1.emt-t-1113662392-1595861228527-2-sdojq.aol. 172800  in  a   
198.41.1.168
emt-ns1.emt-t-1113662392-1595861228527-2-sdojq.aol. 172800  in  rrsig   
a   8   3   172800  20200804181604  20200728181604  32545   aol.
h+iuDHDjmnr5a0egcjKDSiGxSyYe9O4UVJVOL8F3ttqwv31PnNnWyxFoa9k8gyGGBB6155jbJExvCY4KxqHqYPKylVw5Br/zfbFCfXD+wpMEmxHvQbRkDtK7AZBSLNunPl8gJ+WmywX8LVXhjobWCo9VGMogVKJz+cRcFKu/PY97fOzQbnNJBkF473zoPNX0Ct+2C/5QSEd5OYSIVfD2iA==
emt-ns1.emt-t-1158551749-1595861079980-2-xo.aol.172800  in  a   
198.41.1.126
emt-ns1.emt-t-1158551749-1595861079980-2-xo.aol.172800  in  rrsig   
a   8   3   172800  20200804175637  20200728175637  32545   aol.
a4ij0JWJZlHXbPR+At9pYnTrWwpyFI12ubSnMmZ6PhlK4Sed5v64mzVy8QAmbgAtT2kNJqLW/weG4ZGHQDzN/oTYo2+NhLYpqf9/r1CBaX1V3As17lOSx5I7nm5aeKIupYnyMBb/h5NyxIh/7pbYT4fd+AtENKIt1Va+TAsZPBcL6a9dqcajRpnQ3Fx9Tq9QQJQC38sfHEK2X4fjRCF3/w==
emt-ns1.emt-t-1737294735-1595858930228-2-jz.aol.172800  in  a   
198.41.1.92
emt-ns1.emt-t-1737294735-1595858930228-2-jz.aol.172800  in  rrsig   
a   8   3   172800  20200804171915  20200728171915  32545   aol.
FiTCAdK7jDWig2s0Y/duIsKuM86BOoe4jEcYLh9eEI1swnPKmUTWY9aM5xCFr9yqTlWHDz5cX3WzivizMqbhOa7LorQuIU359bh2z9FOk1MWZrhLUk5jhBW8tLT+Lj6lNe8rN4kmfVAU3ScBJ8X+pfALYACkoHdIuZs74fvspxiO/DF7EOH88mmyedyFiZA0NtOzN4lfFLDkPqUgKQL+8g==
emt-ns1.emt-t-1919814529-1595856863287-2-rflv.aol.  172800  in  a   
198.41.1.111
emt-ns1.emt-t-1919814529-1595856863287-2-rflv.aol.  172800  in  rrsig   
a   8   3   172800  20200804165227  20200728165227  32545   aol.
WtEXPHu8fXQ3hDK6qVOmHbcRDMKsXTG2Q3qlJh10zyUCAFATsSvaZtHvmFZX60EvzB5H9qOATjmhd4ondDAoHwwS5+vn2Q8+Gtwl8lbMgv97OjtZTyf+KDKf7zsS+h7+rQtL8xOHSZp04uB6bTGscE7FoFVnXtGLC8efJPpGcIEvXtqx1CQMmA+OfY6Fkff6a0+qD3ZECCWtLbc/KI3pnw==
emt-ns1.emt-t-2040593332-1595870898209-2-fjmc.aol.  172800  in  a   
198.41.1.65
emt-ns1.emt-t-2040593332-1595870898209-2-fjmc.aol.  172800  in  rrsig   
a   8   3   172800  20200804215349  20200728215349  32545   aol.
CKITWMU4hsaZz9sDYLPZOdnqPrGucEb82tPrFe7AUnsKC8uc20OwpaWBZsKiljm1J3khT7LuZFfLpvAC4Ma4c7DFXZBlJU0vwV4ONk5+M6+Ne+kiIYr8FfdAZy/UfgO0PYY0bqFYADINjxhAAcUPabgDQXmyjgHMLJmSXHibCWlD7rNhGbSYnHk2HYljhB3F5Qr5M/9JbgSXySq2XAdVQQ==
emt-ns1.emt-t-320674882-1595861934204-2-ngoj.aol.   172800  in  a   
198.41.1.109
emt-ns1.emt-t-320674882-1595861934204-2-ngoj.aol.   172800  in  rrsig   
a   8   3   172800  20200804183500  20200728183500  32545   aol.
OFH8JEJioRiVjLm9eP2Dxgncj064Mevm9QAV0/Ybj8p0HhhEehlKvwazcTSCymLHN2eKiw8b9jN3Lfvpy2PEh2yXGM+GzJ5/eTLO0RLGV2PuaXYGiFbgze8j48ROw+W9FD7LdP33U2vGXwmn8aHaIAuCvzoIHQAUnDgKTJK9zQYzYj51Ltx0zFZGtibsafKwMvRI7fJcbJgApAJ89tjaSQ==
emt-ns1.emt-t-645432105-1595875144963-2-p.aol.  172800  in  a   
198.41.1.80
emt-ns1.emt-t-645432105-1595875144963-2-p.aol.  172800  in  rrsig   a   
8   3   172800  20200804233833  20200728233833  32545   aol.
KVOc4xcORtulWDbaMxMBATKmBxPz2BKTozKsh9hWmxqAYuJviwRSfFDthojzIWc1rHJocAWTf/0pwQVhYvWeK1w5LH+4v33VxzGOlQKTBYr20etIgChS5JK7ohH4PsZPK0juk+1mvFHoD7DJYeGv3XIkXOEs4+cdsbIOD9hBnWh4OrihJdPGPZIzpiMG21Nplc5CFP+uOGbPZPtdqqdJEQ==
emt-ns1.emt-t-706490806-1595861285174-2-gmk.aol.172800  in  a   
198.41.1.117
emt-ns1.emt-t-706490806-1595861285174-2-gmk.aol.172800  in  rrsig   
a   8   3   172800  20200804182723  20200728182723  32545   aol.
InRAqN/asgig+58aeUI4AqCP7QgMdK/Xr/5soEYRnvUdqXdD6s9vSqVDWhZzbdBNocKnoMo1WBiYUIMBvPoUGCMnAjCuKq5hze654pZAoiQYFatnE+AhNgkRqGdglvlSrP6ou7igOmPOAlMlEgmnwV3psVMJeaAdXI2Zx/460TLSYougRqS9/gCPf5hfinXiRpf4l2InnRypGU25ARapdw==


I don't know if other nameservers implement the same behaviour. AFAIK it
isn't possible to represent orphan glue in standard zone files or zone
transfers, so I think this is an ATLAS special.


Nothing special there, orphan glue that isn't under a delegation is
just an ordinary A record. I suppose they could do an nsec3 opt-out to
provide a hint that it's intended to be glue, but who'd care?

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] [Ext] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt

[John R Levine]

Uh, no. The TC flag means "something didn't fit".
It is not restricted to glue, which is only in the additional section.
TC can also be set if something from the authority section didn't fit, or
if something didn't fit in the answer section.
(Obviously it would be the first section where something didn't fit that
matters.)


Well there's a question.  Is there any DNS software that will keeps adding 
new sections to a truncated answer, e.g., a partial authority section but 
it has some additional records anyway.  Seems unlikely but I honestly 
don't know.


In any event this whols plan still seems way overcomplicated.  In my 
simple world, you can tell that an answer is a referral because it has an 
empty answer section and an non-empty authority section.  A useful 
referral has some NS records in the authority section.


Let's see what other people think.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] [Ext] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt

[John R Levine]

On Fri, 3 Jul 2020, Brian Dickson wrote:

It makes clear the difference between implied and inferred.
The flag clearly indicates that some glue which would otherwise be
considered necessary has not been sent.


That sounds a lot like the TC flag.  I realize that some people have 
interpreted the TC flag to mean something else, but I think its actual 
meaning is pretty clear.



Additionally, the flag would signal compliance with updated 1035, for
starters.


This would in effect be a version number.  Our experience with version 
numbers in old protocols has not been great.



Also, it would facilitate lower effort in figuring out if a TC is referral
related or not, which could be important for implementers/operators doing
large scale stuff.


I don't understand this.  Caches surely already know when a response is a 
referral.  If a referral response has TC set, in what way could that not 
be referral related?



Most importantly, this is all about interoperability, including not just
the wire format but the operational signaling.


Turning on bits that have been zero for 35 years doesn't have a great 
history of interop, either.  Look at the history of queries with EDNS0 
never getting a response.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt

[John R Levine]

On Thu, 2 Jul 2020, Paul Vixie wrote:


until someone invents faster than light travel, round trips and remote state
will be the second and third most expensive things on the internet. (the most
expensive thing is complexity.) i think we can usefully discuss whether to set
TC=1 if the only thing that won't fit is glue, but some glue did fit. but our
goal should be to allow smart initiators to avoid retrying with TCP out of
reflex. my recommendation of TC=0 is to suppress reflexive TCP retries.


I wouldn't disagree but it seems to me once again it's a tradeoff between 
performance and correctness.  I'd prefer correctness, particularly since 
it seems that the option to use what's in a truncated referral gets you 
both.



3. even without TC=1 you will know there's under-zonecut glue you didn't
receive, because you saw the NS RR, and the only path to the address RR is
through that NS RRset.


Well, maybe.  Even if you got one A record there might be others.  Or if 
you got an  record but no A record and you're on an IPv4 network, you 
can't tell whether there's a lurking A record or not, or vice-versa. 
(See the glue for j.zdnscloud.com in the root.)


If we do it your way, if any NS is in-zone and the lookups fail, you 
*always* need to do a TCP query just to see if if the UDP response left 
something out.


R's,
John

PS: I'm less worried about round-robin DNS, since then it's clearly a
deliberate decision by the parent to leave some of the answers out.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[John R Levine]

RFC2606: ".example" is recommended for use in documentation or as examples.


I had my reasons for https://www.mega-xxx-babes.com

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[John R Levine]

 - I think it would make sense for non-TLDs to be DNAME'd to AS112++'s
 empty zone (which generates an NXDOMAIN)


You want this in the root?

* IN DNAME EMPTY.AS112.ARPA.

That'd be, um, different.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[John R Levine]

technically ICANN is only really in charge of the gTLD name space as the
ccTLD one depends on the ISO 2 letter alpha code elements over which
ICANN has no control.


I suppose this might make sense as an informational RFC about here's
what is likely to happen if you squat on these names that probably
will never be in the global DNS.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

Here's one example, 0124.org which has five in-domain name servers with glue:


You're right, that's what it does but it also seems seriously wrong.


$ for sz in `seq 604 16 700`; do echo -n "BUFSIZE $sz " ; dig +norec +ignore 
+dnssec +bufsize=$sz @199.19.57.1 0124.org | grep ';; flags:' ; done
BUFSIZE 604 ;; flags: qr tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
BUFSIZE 620 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1


This domain has five NS, but the client only has the IP address of the 
first one.  If that first one doesn't respond, what happens?  It can't 
query any of the others because it doesn't have any of the addresses and 
it doesn't have any way to ask for them.


What's the point of having more than one NS if clients can only find one 
of them?


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] CNAME chain length limits

[John R Levine]

On Thu, 28 May 2020, dagon wrote:

On Thu, May 28, 2020 at 01:02:47AM +0100, Tony Finch wrote:

dagon  wrote:


  -- Tests for ("improper") horizontal vs. vertical CNAMEs.  Some
 recursive speakers fail; some complain ("BAD (HORIZONTAL)
 REFERRAL", but answer), and some follow without complaint.


Can you explain what these are, please?


If a canonical answer points to the same level as the 'owner name',
then the left and right sides share NS.  (This is the most common
case, and even outlined in 1034.)  If this discovery occurs during a
CNAME chain chase with yet another empty answer, the NS is in a sense
making a referral to itself, or its pool of secondary NS serving the
same delegation cut level---the bad horizontal referral.


It sounds like "horizontal" means within the same zone, and "vertical" 
means a different zone.  I don't know what you mean by "level" -- same 
number of components in the name? All but the last component the same? 
In the same zone?  Something else?


In RFC 1034 CNAMEs are intended as short term transition aidss, sort of 
like yellow forwarding stickers on paper mail.  Now they're mostly used to 
dynamically delegate names across authority boundaries, which works pretty 
well, but there's a lot of ancient cruft still sticking to them.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] CNAME chain length limits

[John R Levine]

While I should have been doing something else, I made a rather long CNAME
chain.  When I looked up chain.examp1e.com it got SERVFAIL, but after I
warmed up my cache five links at a time by looking for chain5, chain10,
chain15, and so forth, it worked.  At least it worked in "dig" and "host".
When I try and look up http://chain.examp1e.com, Chrome waits a while
and says not found,


If Chrome is using its built-in stub, there's not expected to be a limit
(other than the overall message size limits), but nothing tests chains this
long other than security fuzzers that are only looking for crashes or
memory issues.


On my Mac, I get surprisingly consietent browser results.  In Chrome, 
Firefox, and Safari, chain10.examp1e.com works, chain11.examp1e.com fails 
slowly.  From the TTLs I get from dig, it appears that none of them are 
using the resolver to follow the CNAME chains.  For Firefox I have the 
canary domain blocked so I dunno what it is doing.



chain12.examp1e.com.3449IN  CNAME   chain11.examp1e.com.
chain11.examp1e.com.3486IN  CNAME   chain10.examp1e.com.
chain10.examp1e.com.3455IN  CNAME   chain9.examp1e.com.
chain9.examp1e.com. 3455IN  CNAME   chain8.examp1e.com.
chain8.examp1e.com. 3455IN  CNAME   chain7.examp1e.com.
chain7.examp1e.com. 3455IN  CNAME   chain6.examp1e.com.
chain6.examp1e.com. 3455IN  CNAME   chain5.examp1e.com.
chain5.examp1e.com. 3455IN  CNAME   chain4.examp1e.com.
chain4.examp1e.com. 3455IN  CNAME   chain3.examp1e.com.
chain3.examp1e.com. 3455IN  CNAME   chain2.examp1e.com.
chain2.examp1e.com. 3455IN  CNAME   chain1.examp1e.com.
chain1.examp1e.com. 3466IN  CNAME   chain0.examp1e.com.
chain0.examp1e.com. 3460IN  A   64.57.183.119


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] CNAME chain length limits

[John R Levine]

I should also note though that Chrome's built-in stub won't do any followup
queries if the full chain is not in the response from the recursive.


Interesting point -- if the result is truncated will it requery with TCP?



On Wed, May 27, 2020 at 3:03 PM Eric Orth  wrote:




On Wed, May 27, 2020 at 1:49 PM John R Levine  wrote:


While I should have been doing something else, I made a rather long CNAME
chain.  When I looked up chain.examp1e.com it got SERVFAIL, but after I
warmed up my cache five links at a time by looking for chain5, chain10,
chain15, and so forth, it worked.  At least it worked in "dig" and
"host".
When I try and look up http://chain.examp1e.com, Chrome waits a while
and says not found,



If Chrome is using its built-in stub, there's not expected to be a limit
(other than the overall message size limits), but nothing tests chains this
long other than security fuzzers that are only looking for crashes or
memory issues.



Firefox waits a while and says "Hmm. We’re having
trouble finding that site." and Safari on my Mac hangs.  (Feel free to
try
it yourself.)

I realize the answer to most questions like this can be summarized as
"don't do that", but is there any consensus as to the maximum CNAME chain
length that works reliably, and what happens if the chain is too long?
Hanging seems sub-optimal.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

$ dig chain.examp1e.com A
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.10.6 <<>> chain.examp1e.com a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59001
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 102, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;chain.examp1e.com. IN  A

;; ANSWER SECTION:
chain.examp1e.com.  3371IN  CNAME   chain100.examp1e.com.
chain100.examp1e.com.   3371IN  CNAME   chain99.examp1e.com.
chain99.examp1e.com.3371IN  CNAME   chain98.examp1e.com.
chain98.examp1e.com.3371IN  CNAME   chain97.examp1e.com.
chain97.examp1e.com.3371IN  CNAME   chain96.examp1e.com.
chain96.examp1e.com.3372IN  CNAME   chain95.examp1e.com.
chain95.examp1e.com.3372IN  CNAME   chain94.examp1e.com.
chain94.examp1e.com.3372IN  CNAME   chain93.examp1e.com.
chain93.examp1e.com.3372IN  CNAME   chain92.examp1e.com.
chain92.examp1e.com.3589IN  CNAME   chain91.examp1e.com.
chain91.examp1e.com.3589IN  CNAME   chain90.examp1e.com.
chain90.examp1e.com.3583IN  CNAME   chain89.examp1e.com.
chain89.examp1e.com.3583IN  CNAME   chain88.examp1e.com.
chain88.examp1e.com.3583IN  CNAME   chain87.examp1e.com.
chain87.examp1e.com.3583IN  CNAME   chain86.examp1e.com.
chain86.examp1e.com.3583IN  CNAME   chain85.examp1e.com.
chain85.examp1e.com.3577IN  CNAME   chain84.examp1e.com.
chain84.examp1e.com.3578IN  CNAME   chain83.examp1e.com.
chain83.examp1e.com.3578IN  CNAME   chain82.examp1e.com.
chain82.examp1e.com.3578IN  CNAME   chain81.examp1e.com.
chain81.examp1e.com.3579IN  CNAME   chain80.examp1e.com.
chain80.examp1e.com.3570IN  CNAME   chain79.examp1e.com.
chain79.examp1e.com.3571IN  CNAME   chain78.examp1e.com.
chain78.examp1e.com.3571IN  CNAME   chain77.examp1e.com.
chain77.examp1e.com.3571IN  CNAME   chain76.examp1e.com.
chain76.examp1e.com.3572IN  CNAME   chain75.examp1e.com.
chain75.examp1e.com.3564IN  CNAME   chain74.examp1e.com.
chain74.examp1e.com.3564IN  CNAME   chain73.examp1e.com.
chain73.examp1e.com.3564IN  CNAME   chain72.examp1e.com.
chain72.examp1e.com.3564IN  CNAME   chain71.examp1e.com.
chain71.examp1e.com.3564IN  CNAME   chain70.examp1e.com.
chain70.examp1e.com.3519IN  CNAME   chain69.examp1e.com.
chain69.examp1e.com.3519IN  CNAME   chain68.examp1e.com.
chain68.examp1e.com.3519IN  CNAME   chain67.examp1e.com.
chain67.examp1e.com.3519IN  CNAME   chain66.examp1e.com.
chain66.examp1e.com.3519IN  CNAME   chain65.examp1e.com.
chain65.examp1e.com.3519IN  CNAME   chain64.examp1e.com.
chain64.examp1e.com.3520IN  CNAME   chain63.examp1e.com.
chain63.examp1e.com.3520IN  CNAME   chain62.examp1e.com.
chain62.examp1e.com.3520IN  CNAME   chain61.examp1e.com.
chain61.examp1e.com.3554IN  CNAME   chain60.examp1e.com.
chain60.examp1e.com.3549IN  CNAME   chain59.examp1e.com.
chain59.examp1e.com.3549IN  CNAME   chain58.examp1e.com.
chain58.examp1e.com.3549IN

Re: [DNSOP] CNAME chain length limits

[John R Levine]

On Wed, 27 May 2020, John R Levine wrote:
While I should have been doing something else, I made a rather long CNAME 
chain.  When I looked up chain.examp1e.com it got SERVFAIL, but after I 
warmed up my cache five links at a time by looking for chain5, chain10, 
chain15, and so forth, it worked.  At least it worked in "dig" and "host". 
When I try and look up http://chain.examp1e.com, Chrome waits a while and 
says not found, Firefox waits a while and says "Hmm. We’re having trouble 
finding that site." and Safari on my Mac hangs.  (Feel free to try it 
yourself.)


FWIW, the cache is unbound 1.10.1.

R's,
John

I realize the answer to most questions like this can be summarized as "don't 
do that", but is there any consensus as to the maximum CNAME chain length 
that works reliably, and what happens if the chain is too long? Hanging seems 
sub-optimal.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop