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:
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 To
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 | _
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 In
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 recal
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
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
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 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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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, 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
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
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
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
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 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 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
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
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,
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
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
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
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
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
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.
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
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 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
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 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
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, 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
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
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
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
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
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 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
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 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
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
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
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
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
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 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
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 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 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 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
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 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
On Thu, 8 Aug 2019, Joe Abley wrote:
I don't see how that's a MUST. What else could you do?
One alternative would be for the receiver to insist that all digests
with supported algorithms match. It seems reasonable to specify that
verifying that one of them matches is sufficient to declare the
On Thu, 8 Aug 2019, Wessels, Duane wrote:
Thanks John and Joe, does this text capture what you're suggesting?
4.1. Verifying Multiple Digests
If multiple digests are present in the zone, e.g., during an
algorithm rollover, a match using any one of the recipient's
supported Digest Type a
I don't mean to channel Warren (it's unnecessary because even when he's asleep
he's still reading mail) but I think the whole point of the ALT proposal is not
to have a registry. A registry attracts policy and dispute resolution; an
informal, decentralised understanding that anything goes, plea
2. Names handled through mutant DNS which can returns IP addresses (.local,
.localhost, .homenet/.home.arpa)
I think it's clear that nobody has ever shown signs of wanting to anchor
anything like this under .ARPA if it's a name that a user might ever have to
see. The reason we might imagine
On Mon, 7 Oct 2019, Tim Wicinski wrote:
I believe the browser vendors have made such an agreement. We should get
confirmation.
That's about 2/3 of it, but I hope they stay engaged to avoid an outcome
where we make changes that seem OK to us and they come back at the end and
say no, we're not
I just heard a most interesting talk at M3AAWG about postquantum crypto
and particularly about the NIST candidate algorithms. Many of them have
much larger key or signature sizes than any current algorithm, like 10,000
bits or more. Some are a lot slower than others. Has anyone been looking
On Thu, 28 Nov 2019, Doug Barton wrote:
I don't see how relying on ISO's advice is poaching. They say:
You, like Ted, are ignoring the fact that ISO can choose to change those
rules.
The user assigned codes are part of the published ISO 3166 standard. If
that's not stable enough, neither
I do think the semantic meaning of the label is worth thinking about,
and I am wary of particular scripts or languages being chosen
arbitrarily. ...
Part of Roy's pitch was that the reserved two letter codes like .ZZ are
equally meaningless in most languages.
- has the advice to anchor a pri
We seem to have a fairly basic disagreement here about whether we can
expect people who implement ZONEMD to be familiar with the way that DNS
servers work. In pretty much all of the cases below, it seems to me that
if the answer to the question isn't obvious, you're not the audience for
this d
Well, OK, here's a concrete example. I download the COM zone every
day from Verisign, and also a separate file with an MD5 hash of the
main file. Using RFC 2119 language, what do I do if the hash I get
doesn't match their hash? ...
Ok - you've described half of this - the download and the vali
*Sigh* Not exactly. If you have no automated applications that will use
this, then it depends on the human and I think that's what you mean by
"application". Otherwise, I think you'll find that most automated
applications will want to (or probably should want to) use the same logic.
I'm sorr
Could you give me a b) for each of these please? E.g. How does ZONEMD make
your life better in each of these and what would happen if you - in a future
world - were getting ZONEMD data and validation failed?
Unless someone else says they find this level of anecdotal detail useful,
I'll pass.
On Wed, 8 Jan 2020, Michael StJohns wrote:
I'm running a private copy of the root zone for my organization. I
(automated) check the SOA every so often, and arrange for a download of the
zone when it changes. I (automated) get a copy of the zone data, including
an ZONEMD RR, everything valida
Thought I'd forgotten about this? :-)
No such luck, but I'm done. I don't see any benefit in further argument.
On 1/8/2020 3:13 PM, John R Levine wrote:
On Wed, 8 Jan 2020, Michael StJohns wrote:
I'm running a private copy of the root zone for my organization. I
(auto
If the root zone hand a ZONEMD in it, for the first time I'd have a way to
validate the IP addresses in the *.root-servers.net glue records.
Someone suggested you could validate them by trying a query and seeing if
you get a answer, which is of course wrong. That tells you you've found a
serv
You might take a look at RFCs 8552 and 8553. There is a long history
of publishing stuff in the DNS with scoped identifiers.
All the uses mentioned defined so far are about service discovery.
Not at all. _dmarc publishes info about mail sending policy,
_dkim about message validation keys, a
I made some twiddles to my dbound-in-dns library and updated the I-D to
match.
Code: https://github.com/jrlevine/bound
I-D: https://datatracker.ietf.org/doc/draft-levine-dbound-dns/
I added some more records to the DNS zone so now I believe that by careful
abuse of DNS wildcards, in most case
Remember that in ICANN contracted TLDs and in some ccTLDs, a registry
can only contact registrants by going through the registrars.
So they sent the notices via the registrar. There is nothing preventing
that.
Actually there is -- there's no mechanism to do so. Registries and
registrars com
The plan in this draft is that NS2 would eventually replace NS records.
if so there's a much larger set of changes we'd have to consider. for one
thing NS2 should be slabbed (one record containing a compound rdata set); for
another it would have to incorporate what DS does now (also as a slab).
On Thu, Apr 30, 2020 at 9:44 PM John Levine wrote:
I think it's benign to allow any sort of record as an immediate child
of the domain, since you need to go two levels down for split zones.
That handes the nominet and zz--zz cases.
Is there any chance that a user trying to reach https://examp
In a sense, a glue record with the same owner name as a zone cut could be
equivalent to a glue record with an owner name that is subordinate to a zone
cut. I don't have enough of the spec in my head to know why they would
definitively be different from the protocol perspective. I realise it's n
On Thu, 21 May 2020, Warren Kumari wrote:
Yes -- but information in the additional section should not be
promoted to an answer.
A week or two ago I scannned TLD zone files to see how many signed A and
records there were. Quite a lot, most looks to be orphan glue in
Afilias zones that th
On Fri, 22 May 2020, Tony Finch wrote:
I vaguely remember a policy change in .com and .net years ago when they
stopped including orphan glue in the zones. Was this to do with prep work
for DNSSEC? I'm slightly surprised .org didn't follow suit.
I believe that the policy is to remove orphan glue
On Fri, 22 May 2020, Joe Abley wrote:
I think that some of the things you have been looking at concern orphan glue,
John -- glue records that have been promoted to authoritative, signed RRSets in
the TLD zone following the removal of a zone cut.
I think what Warren is talking about is the beha
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".
Wh
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
ed, 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.
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
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 comp
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
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 proba
- 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 conside
1 - 100 of 339 matches
Mail list logo
