Someone proposed this approach to prevent NSEC zone walking while doing
static signing:
Divide your zone into the public names and the private names
Sign the two sets separately
Throw away the NSEC records from the private set, then merge them, so the
names from private set only have RRSIG
On Tue, 22 Jul 2025, Philip Homburg wrote:
I'm not aware of any part of the DNSSEC standards, key rolls, operational
practice, etc. that leads to invalid RRSIGs.
You could have TTL issues so that a DNSKEY expires before all of its
RRSIGs, but that seems easier to fix than tag collisions.
So
On Wed, 16 Jul 2025, Philip Homburg wrote:
The problem is that recursors just set random limits that seem to work most
of the time. On the authoritative side, these limits are largely unknown,
let alone the effect on validation of errors in multiple zones.
Recently as a result of reports of pote
On Mon, 14 Jul 2025, Warren Kumari wrote:
We could say that signers MUST NOT create colliding key tags, and that
verifiers and similar tooling must continue to work as they currently do.
If you really want to do this bad idea, the least bad way to do it which I
think someone already suggested
On Mon, 14 Jul 2025, Mark Andrews wrote:
John you keep stating that everything is working ok. We only have a small
percentage of all responses signed, multiple signers are already enforcing the
desired behaviour. There is also no requirement that every key signs every
RRset so there isn’t alw
On Sun, 13 Jul 2025, Warren Kumari wrote:
Is there any actual downside to saying something like "if the new key has a
colliding keytag, just throw it away and try again"? And if you have
multiple signers, partitioning the space both allows this, and provides a
quick signal to a zone owner who is
On Wed, 9 Jul 2025, Petr Špaček wrote:
https://docs.google.com/presentation/d/1snTpkDcRmJN8bbGx9XrOt5taUdS1xSElMB1Ok8s7Kko
I take that as an argument to forbid it!
107 sounds like perfectly tractable number to fix. The two flag days had
wy wider reach, for example, and way more domains go
On Mon, 7 Jul 2025, John Levine wrote:
It appears that Shumon Huque said:
Please review the draft and speak up if you have comments, and would like
to see this draft adopted (or not).
I don't hate the draft but since we have been living with colliding tags for two
decades and experience show
On Tue, 8 Jul 2025, Paul Wouters wrote:
A better solution would be for resolvers to detect when they are under keytag
DoS, and then take counter measures - not for the protocol to be changed and
made more complicated.
Exactly. Malicious (or I suppose buggy) signers can publish colliding
key
On Sun, 6 Jul 2025, Tommy Jensen wrote:
"... without sufficient explaination [sic] for why UDP is a preferable
transport to TCP ..."
I'm with Joe, "because it still works OK." We all know how long the tail
is so it's going to be a very long time before anyone can turn off UDP.
I'd think tha
On Wed, 18 Jun 2025, Mark Andrews wrote:
And if the stubs are validating then the answer for 10.in-addr.arpa DS is a
provable NOERROR NODATA response that says there is a delegation at that point
in the tree. That validator does NOT need to be configured to say ‘DO NOT
VALIDATE THIS NAMESPACE
On Wed, 11 Jun 2025, Erik Nygren wrote:
There are two cases here:
1) Accidental retention of zone contents (this seems unlikely, but worth
mentioning)
No, unless someone has actually seen it happen. It'll just confuse
people.
2) Malicious reintroduction of zone contents (this is the conce
On Sun, 8 Jun 2025, Erik Nygren wrote:
Rather than saying "I authorize this action" in a one-off validation,
persistent validation is saying "I authorize this User/account"
I don't see a useful difference. Either way the entity issuing the token
uses the unique token to identify whatever it i
On Fri, 6 Jun 2025, Paul Hoffman wrote:
This is an OK start, but it would be better if the draft covered the actual
security issues (on-path attackers) and dealt with time more carefully.
Persistent validation doesn't need the token that is needed by the initial
validation.
Why not? Let's s
On Fri, 30 May 2025, Paul Wouters wrote:
and if you're going to do that, you know where to find ACME.
Indeed, but is a cron job really a method to confirm continued
acceptance of a service? It requires credentials to make a DNS
change and in a way only weakens the security model. (just like ACM
On Fri, 30 May 2025, Joe Abley wrote:
I have definitely received automated email telling me that my domain is about
to be detached from a particular service because the TXT record had been
removed. Other TXT records I have been removed in the interests of hygiene had
no such effect.
I agree th
On Thu, 29 May 2025, Paul Hoffman wrote:
When I look at the TXT records on any large organization's DNS apex, I find it
hard to believe
that all of those records are just one time DCV that they forgot to remove.
Correct: there's a good chance they left them there because they don't know if
th
On Fri, 9 May 2025, Michael De Roover wrote:
As far as relevance goes, I don't think that funneling as much of the .lan,
.corp, ... usage as possible into .internal would be a bad thing.
I think it is a fine idea. But I do not think that means we should screw
around with the DNS to make a hal
On Fri, 9 May 2025, Michael De Roover wrote:
I dunno, my name is not Kim. But if it is to go into the PSL, then probably it
should go into the IANA doc first. I mean, the more consensus on this .internal
name, the higher the chance it gets actually adopted, right?
Consensus is a very loose term
On Tue, 6 May 2025, Philip Homburg wrote:
Adding an insecure delegation is a good way to tell validators that there is
going to be an insecure zone. It is a practical mechanism that is proven to
work.
I have no clue how to design a protocol where a mobile device can attach
to an unknown network
On Fri, 2 May 2025, Ben Schwartz wrote:
My personal unsupported assumption is that the number
of devices in the "we use the cache but don't believe what it says" camp is
small enough not to matter.
I expect you're right today, but there are definitely some folks in
DNSOP who are trying to chan
On Thu, 24 Apr 2025, Wes Hardaker wrote:
"John Levine" writes:
There are 43 two letter "user assigned" ISO 3166 codes that will never
be assigned to geographic places, so I think it is safe to assume they
will never be TLDs.
I'd argue we shouldn't me making specifications that based on "safe
On Sat, 19 Apr 2025, Philip Homburg wrote:
about some way to keep the local DNS hacks in sync throughout a
network for the people who don't use their cache as the source of
DNS truth.
There is a simple way to solve this. Just add a negative trust anchor for
internal to DNSSEC validating softwar
On Sat, 19 Apr 2025, Philip Homburg wrote:
In your letter dated 18 Apr 2025 17:43:59 -0400 you wrote:
I use unbound, which by default serves empty stubs for all these zones,
along with the RFC1918 rDNS. In practice it works fine.
Yes, I know that part works.
I run a validating proxy on my la
On Fri, 18 Apr 2025, Philip Homburg wrote:
If I were using .internal names, I would configure them in unbound
exactly the same way that I configure the rDNS for 192.168/16 and
onion and the other zones it's preconfigured to serve. If you ask
for DNSSEC, it says it's unsigned.
If someone is abo
On Mon, 10 Mar 2025, Victor Zhou wrote:
knowledge is invaluable and difficult to obtain just from reading RFCs. I
will try to ask more questions before making assumptions about RFC history
and I'd appreciate any recommended resources to better understand
the actual history of these efforts and th
On Fri, 7 Mar 2025, Victor Zhou wrote:
John - Yes, I am aware of RFCs 8552 and 8553 and the IANA registry for DNS
Underscore Names that 8552 creates. Our intention is *not* to compete with
or replace the underscore naming scheme, but rather to provide a
complementary approach specifically focused
On Fri, 7 Feb 2025, Peter Thomassen wrote:
From an OPSDIR point of view, I noticed that some references about the
deployment are provided in section 7 on "Implementation Status". Since this
section is supposed to be removed before publication, I would rather keep
it
and summarize the main resul
On Sat, 1 Feb 2025, Paul Hoffman wrote:
a TXT foo bar
b TXT "foo bar"
The first one has two strings of three characters each, the second has one
string of seven characters, and they mean different things.
The fact that RFC 1035 didn't define this well has been discussed ad nauseam for
>30 ye
["DUJ", [["add", "yourname.example", "TYPE4321", "\# 4 0A01"]]
IF you put quotes around it, you'll get the wrong answer.
I assumed that software that is updating zone files would know this; the
examples in RFC 3597 are pretty clear about that. But I"ll add a note
about that because differ
On Thu, 26 Dec 2024, Shumon Huque wrote:
On Thu, Dec 26, 2024 at 3:48 PM John R Levine wrote:
On Thu, 26 Dec 2024, Shumon Huque wrote:
However, I guess for online signers, there is in fact a small
computational
advantage in not needing to dynamically construct a signed NSEC3 record
in
On Thu, 26 Dec 2024, Shumon Huque wrote:
On Thu, Dec 26, 2024 at 2:05 PM John Levine wrote:
Someone is going to ask what about opt-out. I think the answer is that when
doing online signing it's easier to sign everything than try and find the
names whose hashes precede and follow the name you do
On Tue, 24 Dec 2024, Edward Lewis wrote:
Remember that the notification is just a hint. Whatever receives the NOTIFY
might decide
to try the update on its own, so I don't see any new issues here. You're right
that if a
CDS key roll doesn't happen, there is no way to tell the child what the prob
On Thu, 7 Nov 2024, Stefan Ubbink wrote:
You have to know what kind of version numbers the database uses to
know what the value means. I agree this is a private extension.
I would argue that you wouldn't need to know what the value means, if
it is a number and it always changes in a predictabl
On Sat, 5 Oct 2024, Philip Homburg wrote:
Other way around, if the client doesn't understand NXNAME, the recursive
needs to get the real signed NXDOMAIN to pass along.
If a recursive resolver passes NXDOMAIN to a requesting validator, then
the result has to prove NXDOMAIN, so there has to be ei
On Sat, 5 Oct 2024, Philip Homburg wrote:
If a stub resolver askes for a.b.c.d.example and d.example does not exist
then example is the target zone. It is also a TLD, but if d.example does not
exist then any query for a.b.c.d.example is directed at the zone example.
Right.
The question then b
On Fri, 4 Oct 2024, Vladimír Čunát wrote:
special handling" should say that resolvers MUST implement the response code
restoration in 4.1 unless the client sends the EDNS0 Compact Answers OK
option.
You can't restore the RCODE by default. This topic is repeating. Such
answers must not pass
On Sat, 27 Jul 2024, Edward Lewis wrote:
As part of my answering to "further exploration", I’m skeptical that it
is possible eliminate key tag collisions from the protocol. Not that
collisions are in anyway desirable or are worthy of being tolerated, my
skepticism is whether or not elimination
Even if we where to go with one failure is allowed we still need to
write down the new rules and there will be complaints that we are
retrospectively changing the rules. This is grand fathering in the
old rules for the old algorithms.
Write a BCP, not a standard disallowing key id clashes.
Ri
On Fri, 26 Jul 2024, Erik Nygren wrote:
On your last point, yes, I think we can say that if a verifier sees
multiple validation records, they can abort.
I'd think it would be better to allow looking at the full RRset and
succeeding if any of the records match?
No. These records are suppose
On Wed, 24 Jul 2024, Shumon Huque wrote:
The issue is that a wildcard will match every possible owner name. If you
are confident that there is enough entropy in the tokens that no verifier
will ever be confused, OK. But since the token is supposed to be the only
thing at the _prefix name, how a
On Tue, 23 Jul 2024, Shumon Huque wrote:
The simplest thing to do would be to follow the precedent of SPF,
DKIM, etc TXT using protocols and state that multiple TXT strings
(if present) need to be concatenated before use. We can state
this.
That should be fine.
Wildcards can cause some annoyi
On Thu, 11 Jul 2024, Tim Wicinski wrote:
The stanford.edu example is useful, only because they don't show up in
those alexa top-1000(000) lists.
Like I am sure many here have, I dumped the TXT records to the top 1000 and
while the majority use
the format "token=value", there are several that use
On Thu, 11 Jul 2024, Tim Wicinski wrote:
A) Should verification records have a tag at the front of the data to
identify the record type? There's plenty of prior art for this, e.g.,
the 63 text records at stanford.edu. Or you might say that a
sufficiently long random token in the interesting part
I took a look and didn't find anything particularly troubling. I agree
that adding the new optional DNSKEY element doesn't need a version number.
Getting rid of private certificates in favor of a CA signed cert for the
HTTPS server makes sense.
On the other hand, I don't understand what the p
On Mon, 24 Jun 2024, Joe Abley wrote:
It seems like it would be nice to be able to implement future new RRTypes like WALLET
simply by adding an RRType to an array of RRTypes that are all implemented the same way,
rather than writing new parsers for every one of them. It would also make applican
It currently says:
A name server MAY include more than one ZONEVERSION option in the
response if it supports multiple TYPEs. A name server MUST NOT include
more than one ZONEVERSION option for a given TYPE.
Here is a real life example from my server sdn.iecc.com:
;; QUESTION SECTION:
;com.ws
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
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 anch
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
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
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 86
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 eac
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 certa
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 diff
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
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 doe
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 a
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 requi
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 th
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 so
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 curr
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 t
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
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 I
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 noneth
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.
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" -> "li
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
w
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 tota
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 t
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 al
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,
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
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
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
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) pu
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
updat
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 i
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 k
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
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
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 kno
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
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 ca
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 arg
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
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
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 consistentl
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
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
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 m
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
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
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
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 name
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 r
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
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 subdo
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 p
1 - 100 of 376 matches
Mail list logo
