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
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
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:
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
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
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
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
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
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
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
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
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
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
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" ->
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
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
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
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
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
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)
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
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 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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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:
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
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
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".
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
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
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:
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
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
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
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
*
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
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 readi
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.
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
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.
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
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
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"
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
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
(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
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
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
_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
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
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
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.
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
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
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
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
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
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
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
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
- 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
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
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
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
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
, 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
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
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".
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
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
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
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
1 - 100 of 310 matches
Mail list logo
