On 21 Jul 2024, at 15:54, Edward Lewis wrote:
> I don’t think there’s any good to come from shrinking an in-memory size of
> the zone this way. Saving space, sure, but I don’t think the cost in code
> complexity will favorable.
This sounds right to me.
> I see this as a UI issue. A (secure)
The draft reads very different than the email message. The draft sticks to a
protocol definition while the email describes a use case. This difference is
significant.
Reading the draft (no use case assumed), my first question is how “www.subpage”
would be encoded (referring to section 4.1’s w
Hi Alexander,
My response is also inline:
Alexander Robohm schreef op 2024-07-21 21:44:
Hi Ben,
- The DNS UPDATE RFC redefines the question section as the zone
section. This means that the DNS server already doesn't extract the
target zone from the record name, but from the zone section. A
Hi Ben,
- The DNS UPDATE RFC redefines the question section as the zone section.
This means that the DNS server already doesn't extract the target zone
from the record name, but from the zone section. A relative record
should therefore be added to the zone mentioned in the zone section.
- The
Hi Alexander,
Thank you for your response.
- The DNS UPDATE RFC redefines the question section as the zone section.
This means that the DNS server already doesn't extract the target zone
from the record name, but from the zone section. A relative record
should therefore be added to the zone m
Hi,
I have read your draft and have a few questions:
- How does the server receiving the UPDATE decide where too put it? The
draft, AFAICT, doesn't specify what domain should be appended to the
relative label to fully qualify it.
- How are multi-label relative names handled? (say selector._do
Dear all,
In the recent years I started working on my own coded DNS server,
because I was done with the synchronization between BIND and DirectAdmin
that broke all the time. It resulted in a Java server that is running on
4 IPs for some years now. Because of this, I had to read many RFCs to
h
Issues
--
* ietf-wg-dnsop/DNSOP_Doc_Tracker (+0/-0/💬1)
1 issues received 1 new comments:
- #15 draft-hardaker-dnsop-rfc8624-bis et al (1 by moonshiner)
https://github.com/ietf-wg-dnsop/DNSOP_Doc_Tracker/issues/15 [Authors] [WG Document] [2: DNSSEC] [4: Maint]
Repositories tracked
