gner (DS) Resource Record (RR) Type Digest
Algorithms Column Values"
It should be "table 3" in the text and under the table.
And the header for each page has a placeholder "title" instead of the
actual title.
--
Bob Harold
On Thu, Mar 21, 2024 at 9:25 PM IETF Secr
he best
> way to address the resource consumption problem than can exacerbate.
> Ruling them out of bounds doesn't mean they can't come back on the field
> and cause problems. Treat the problem - resource consumption - that can be
> done.
>
> And don't design a new protocol with a key tag
nt was...don't include
> this idea in a future design.
>
> " don't include this idea in a future design."
But if I have a 'standby' DS record, to allow faster rollover if a key is
compromised, then there will always be two DS records. And without a key
tag or
I thought key collisions were only in a single domain. Anytime you are
looking for a key tag, you already know the zone. Collisions across zones
don't matter, unless your implementation is only tracking keys by tag and
not by zone.
Or am I missing something?
--
Bob Harold
>
> On Tue, Feb
I don't think we can completely avoid tag collisions in a multi-signer
situation. They could detect and correct a collision, but due to the long
TTL's in many TLD's, that could take 24 hours. So I think resolvers should
allow for at least a few collisions and not fail on the first one.
--
Bob
ckground and Motivation
Recursive server may replace a forged answer to a query with a
configured answer of the authoritative server
Seems reversed. It should be:
1. Background and Motivation
Recursive server may replace a configured answer to a query
from the authoritative
DP with
> > COOKIES is a source ip validated transport.
>
> Imagining that we fixed the phrase to accommodate the case of UDP
> transport with cookies, why?
>
> Joe
>
> I like "source IP validated transport" but perhaps we could say
"transports that are prot
ent, which is 2^31 (not 2^16). Is
that a typo, or is there a reason for the small range?
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Fri, Oct 6, 2023 at 8:54 AM Shumon Huque wrote:
> On Fri, Oct 6, 2023 at 8:20 AM Bob Harold wrote:
>
>>
>> On Thu, Oct 5, 2023 at 6:16 PM Paul Hoffman
>> wrote:
>>
>>> On Sep 14, 2023, at 18:46, Tim Wicinski wrote:
>>>
>>>
C signed and can be validated, so a
rogue server can only block service, not give wrong answers that pass
validation.
Could something like that be included?
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> My $.02.
>
> Mike
>
>
> I thought the catalog zone was required to be a valid zone. We certainly
should not be requiring changes to the code that verifies a valid zone. Is
an NS record part of the validation in some DNS code bases? If so, it
should be mandatory. Do the RFC's re
On Tue, Jun 28, 2022 at 10:23 AM Peter Thomassen wrote:
> Hi Bob,
>
> On 6/28/22 16:20, Bob Harold wrote:
> > But the parent NS set is not covered by DNSSEC, and thus could be
> spoofed??
> > (Wish we could fix that!)
>
> The parental agent (registry, registrar) h
that Updates: 7344.
>
> Sure, I'm volunteering to write up something. I'll wait until Thursday or
> so, in case others share thoughts I should know before I start.
>
> Thanks,
> Peter
>
> --
> https://desec.io/
>
>
But the parent NS set is not covered by DNSSEC, and thus could be
spoofed??
(Wish we could fix that!)
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
omain",
but once you have your first signed domain, then use an NS in that domain
to bootstrap the rest, so it really becomes a one-time event per
organization.
--
Bob Harold
On Wed, Jun 22, 2022 at 8:40 AM Paul Wouters wrote:
> Unfortunately, the reverse zone is very often out of reach for th
en desec.io). If you would
> > try to mean it as this protocol and old software reads it as
> > traditional, that software would abort too if it is unsigned. So I don't
> > think you can accidentally break things either?
> >
> >> It's not explicit what's meant, so there's an ambiguity. Worse, if
> >> you add or remove the delegation at dedyn.io_boot.ns1.desec.io, the
> >> meaning of CDS/CDNSKEY records at that name silently changes.
> >
> > But the meaning only changes from one invalid use to another invalid
> > use?
> >
> >> So, yes, the DNS is good at naming things differently, but we have to
> >> create a naming scheme that is free of collisions.
> >
> > I am not convinced. See above. I think it is clear based on where the
> > (C)DS records are and who would even query for it at that particular
> > location.
> >
> > I don't think it helps scaling either because large zones are pretty
> > trivial these days and all these records are fairly short lived
> > (days). I doubt we will see 60M of these on 1 nameserver. Can you (or
> > John) explain what you think is the scale that would no longer work on
> > a DNSSEC system? And how would that scaling compare to the CPU/disk
> > required to generate new DNSKEYs for all those new DNSSEC domains,
> > signing the domains and creating CDNSKEY/CDS records for them?
> >
> > And regardless, you can create delegatations for com._boot just as
> > easilly as ._boot.
> >
> > I think it only helps prevent hitting the theoretical but non-real
> > FQDN limit of 255, but as I said before, anything that prepends an
> > _underscore prefix will always have a limit under 255. Not using hashes
> > would reduce the max length to 128 minues the _boot prefix length versus
> > 255 - 64 (length of base64(sha256)) - _boot prefix length. So more or
> > less reduce support of FQDNs from ~200 to ~128. This already requires a
> > minimum of 3 subdelegations, but since most TLDs dont exceed ~10 to
> > ~20, would require 4+ delegations. At which point you should really be in
> > part of the DNS tree where you control all parties to provision zones
> > without needing the bootstrap, that is mainly aimed at Registrar - DNS
> > Operator limitations. Eg you would be using catalog zones with your
> > nameservers that would be able to do CDS -> DS because of existing XFR
> > or NSUPDATE based trust relationships, or would even run on the same
> > nameserver to completely automated DS updates when hosting both child
> > and parent.
> >
> > Anyway, just to reflect, I _do_ like and this idea, but strongly prefer
> no
> > hashing and not using it to go two delegations deep over unsigned
> parents.
> >
> > Paul
>
To avoid (C)DS at an apex under the _boot tree, one could use another _name
like:
_nsboot.dedyn.io._boot.ns1.desec.io. CDS ...
So the CDS records in this new scheme are never at an apex, but one level
down under a new "_nsboot" label.
It adds another label, but avoids any ambiguity.
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
repo (https://github.com/paulehoffman/draft-hoffman-dnssec).
> If nothing big comes up, I'll ask for WG Last Call.
>
> --Paul Hoffman
>
>
Looks good to me. Although as a user preparing to deploy DNSSEC, reading
and understanding and applying all those RFC's is ov
F datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/
>
> There is also an HTML version available at:
>
> https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-bootstrapping-00.html
>
>
Interesting idea.
Minor e
If you sign your zone with several algorithms, and mark them all 'Strict",
you are asking my resolver to do extra work. I will probably configure my
resolver to only validate with one algorithm. Maybe the strongest, maybe
the least cpu intensive, my choice, not yours.
--
Bob Harold
O
ore clearly distinguished and protected separately
> using cryptographic signatures.
>
> It is not at all clear that this is a good idea. To restate in
> stronger terms, the goal of the experiment described in this document
> is to determine just how bad an idea this is.
&
If an attacker is spoofing responses, it seems that they could send a
different NS and A record, and a new calculated DS hash. So this provides
no protection against spoofing?
We would need instead (or in addition) an RRSIG record to actually protect
this.
An example would help.
--
Bob Harold
ess to a domain is designated for use
with the "Forged answer" extended error code. This is a string
encoded as UTF-8 characters. This is a string encoded as UTF-8 characters.
-- The last sentence is duplicated (This is a string encoded as UTF-8
characters.)
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ng your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 26 June 2020
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
>
Support, will review.
Just read it - quite an exhaustive study of the subject.
--
Bo
y stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 8 June 2020
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
>
Yes, and I will review.
--
Bob Harold
sues,
even if the response validates correctly. Is there something that I can
match on to get just the responses that fail? (user gets SERVFAIL instead
of an answer) ?
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Thu, May 14, 2020 at 10:25 AM Mukund Sivaraman wrote:
> Hi Bob
>
> On Thu, May 14, 2020 at 10:02:45AM -0400, Bob Harold wrote:
> > I am preparing to enable DNSSEC validation, so I am working on alerts for
> > failed validations, so I can see whether they are user errors
; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu May 14 09:51:53 EDT 2020
;; MSG SIZE rcvd: 56
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
catalog zones MAY allow the catalog to contain
other catalog zones as member zones."
It seems ok to me to allow catalog zones to include other catalog zones as
future feature, although I cannot figure out yet how that would work, but
it might conflict with:
"6.1. Implementation No
pending on the
> validity
> interval.
>
I agree. The amount a clock is likely to be out of sync is not related to
the signature lifetime in any way. A fixed value based on likely clock
skew or operational experience would be better.
(Just my opinion, not meaning to sound like an author
On Wed, May 6, 2020 at 12:16 PM Daniel Migault wrote:
>
>
> On Tue, May 5, 2020 at 2:53 PM Bob Harold wrote:
>
>>
>> On Tue, May 5, 2020 at 12:02 PM Daniel Migault
>> wrote:
>>
>>> Hi Bob,
>>>
>>> I apology the previous email h
roles
"Validating Resolver: A validating that" -> "Validating Resolver: A
validating resolver that"
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
I would prefer the second method. I think that is what some software
already does. (BIND?)
--
Bob Harold
>
> Please inline other comments.
>
> Yours,
> Daniel
>
> [1]
> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dns
Looks useful, I will review.
--
Bob Harold
On Mon, May 4, 2020 at 3:13 PM IETF Secretariat <
ietf-secretariat-re...@ietf.org> wrote:
>
> The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in
> state Call For Adoption By WG Issued (entered by Tim Wicinski)
&
an glue A record for example.com instead of the A record in the
real zone?
(Just trying to think of cases where orphan glue might make a difference.)
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
between an existing member zone's name and an
incoming member zone's name (via transfer or update), the new
instance of the zone MUST be ignored and an error SHOULD be logged.
-- I do not understand. Can you give an example?
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
I support and will review.
--
Bob Harold
On Tue, Apr 14, 2020 at 11:48 AM Tim Wicinski wrote:
>
> This starts a Call for Adoption for
> draft-fujiwara-dnsop-avoid-fragmentation
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-a
On Mon, Apr 13, 2020 at 4:59 PM Shumon Huque wrote:
> On Fri, Apr 10, 2020 at 12:51 PM Bob Harold wrote:
>
>> Having read through the draft, and twice through the emails, I think the
>> draft has the right balance in using the parent and child NS RRsets
>> properly.
quot;additional
data" in every response.
--
Bob Harold
On Fri, Apr 10, 2020 at 11:53 AM Tim Wicinski wrote:
> (as a chair)
>
> I enjoyed reading the thread on dns-operations, and as a chair,
> both Benno and we like where this is going.
>
> (consider this a gentle nudge w
mote root server."
"would all validate" -> "would validate all"
2. Requirements
(second bullet point)
"The system MUST have an up-to-date copy of the Key Signing Key
(KSK) [RFC4033] used to sign the DNS root."
-- Should we clarify as "the public porti
Just my opinion, but I would like to focus on HTTPSSVC first, for a quick
win. Then work on ANAME - it might not be used much anytime soon, but if
it reaches 99% of the DNS servers in 10 or 20 years, it could solve the
problem at the apex for future generations.
--
Bob Harold
On Sat, Feb 22
to use and might be a bit
> confusing to non-native speakers like me. I'm also confused about
> "exactly analogical". What would inexactly analogical be? :)
>
>
> Being another non-native speaker, I am open to suggestions
>
>
>
"analogous" is a more common form of the word, and could be used. Or a
synonym like "parallel" or "similarly".
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
o operate their infrastructure with appropriate
> levels of caution.
> Blindly turning on processing of ZONEMD on zones from random senders might
> not be wise.
>
> Brian
>
Good point. Perhaps the RFC should recommend that there be per-zone
options for enabling ZONEMD processing, and perhaps rate limits?
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
: Legacy
> Stream : IETF
> Verifying Party : IESG
>
>
I agree that "complete" is much better than "unique".
But if we are updating it, could we consider a better word than "forward"
? Actually "backward" would be correct, although I prefer "from the back
to the front" as used elsewhere.
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
at is the meaning of "sensible" here, and is there a better word?
7.1. Trust Anchor Configuration
"Similarly some some domains may present different views"
"some some" -> "some"
11. Invalid Reporting Recommendations
"A DNSSEC validator receiving a D
nt's state at
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/
>
>
I read through it, and it looks good to me.
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Keep TC bit in EDE and move it forward.
I would prefer not to create a DP flag bit yet, until actual measurements
tell us that it makes a measurable difference - let's wait until EDE is
deployed and someone can measure the occurrence of truncating just EDE.
Then we can discuss if the percentage is worth the complexity.
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Paul. Looks good, kinda scary.
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
n the RRTYPE name. We need a stable name that we all can live
>> with.
>>
>> I'll start. Please chime in!
>>
>> Since it seems that many people like SVCB, and many don't like HTTPSSVC
>> (too many repeated SS's!), I sug
2. Requirements
"Another method to have the resolver" -> "Another method is to have the
resolver"
(add the word "is" to make it read better)
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
rewrite:
5. Incremental deployment
The proposed method supports incremental deployment.
When a full-service resolver implements the proposed method, the
full-service resolver avoids IP fragmentation in DNS.
When an authoritative server implements the proposed method, the
representation of an existing
> registry and should be handled as a separate task.
>
> Finally, one reason why we would like to see this draft adopted is because
> we’d like to use it within a real world DNS server implementation..
>
> B
prove
some cases where the client is not acting in an optimal way, but I can
understand why that would be discouraged.
Should we warn implementers of the issues, but still not forbid acting on
them?
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
n open topic
>for discussion. "SVCB" and "HTTPSSVC" are meant as placeholders as
>they are easy to replace. Other names might include "B", "SRV2",
> "SVCHTTPS", "HTTPS", and "ALTSVC".
>
Looks good
00
>
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-resolver-information-00
Minor confusion?
Section 2 Retrieving Resolver Information by DNS
"they only need code to handle the RESINFO RRtype that is not in"
"not" seems wrong here. They o
the 6761 process, but that doesn't seem to be the case, or, if it is,
> I cannot find a reference; if there is anything saying so, can someone
> please send a link?
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
ple digests is good for algorithm rollovers.
It would be nice if the receiving end could warn (without failing) if it
did not recognize the new algorithm.
If the new algorithm was known but did not verify, I don't know whether to
pass or fail, but at least warn.
I don't see a good way to specify that, so i
nse is not warranted.
>
>
> Joe
>
I am also concerned about data leaking, and special handling by the server.
I just had what might be a crazy idea.
What if the covert data was encrypted, and could be transferred normally,
but only someone with the key could read it?
It could then be p
kward compatibility, this is a more easily
> solvable problem.
>
If you are looking at putting it outside the zone, it occurs to me that any
of the IPAM solutions have a database where you can attach information to
records, zones, IP addresses, etc. Even Active Directory can probably do
that.
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Thanks for explaining that. I leave it up to you if a comment to that
affect in the draft would avoid the same question in the future.
--
Bob Harold
On Wed, Jul 10, 2019 at 5:12 PM Mark Andrews wrote:
> is the base64 encoding of 3 zero octet. If named was using a hex
> en
named.conf. Some end-of-life versions do not
support HMAC-SHA256.
key "." {
algorithm hmac-sha256;
secret "AAA=";
};
-- Does a key of 256 zeros translate to a string of "A" characters? I am
not an expert on HMAC-SHA256.
--
Bob Har
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
It depends on how it was "taken down". I thought a proper take-down was to
change or remove the NS records from the parent zone. Then we would get an
authoritative NXDOMAIN and not a lame response.
In that case, a lame response should still serve stale.
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Thu, Jun 13, 2019 at 6:34 PM Brian Dickson
wrote:
>
>
> On Thu, Jun 13, 2019 at 1:51 PM Bob Harold wrote:
>
>>
>> On Thu, Jun 13, 2019 at 1:50 PM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>>
>>>
>
amental problem with ANAME
> if sibling records are required.
>
> Brian
>
I see two main cases:
- ANAME replaces a CNAME record, so that other records can be attached
to the same name. I don't think this is likely to be a big use cas
t;https://tools.ietf.org/html/draft-moura-dnsop-authoritative-recommendations-04#ref-Moura19a>]
shows that
the change in TTL for .uy TLD from 1 day to 5 minutes reduced the
RTT from 15k Atlas vantage points significantly: the median was
was a capability signal
in the request that indicated that the requester would understand ANAME, or
at least not have a problem if it were in the answer section. I am
guessing that the capability signal would be some EDNS option, or perhaps
an EDNS version. Is that reasonable?
--
Bob Harold
_
>
> RFC 1034 says it's "To be defined" so this seems a little premature.
>
> Other than that, go for it.
>
>
Does this increase or decrease the 'camel' page count?
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
inor nit.
5.1. Zone transfers
"Secondary servers that rely on zone transfers to obtain sibling
address records, just like the rest of the zone, and serve them in
the usual way (with Section 3 Additional section processing if they
support it)."
That's not a complete senten
On Wed, Apr 10, 2019 at 4:42 PM Richard Gibson
wrote:
> Responses below.
> On 4/9/19 16:04, Bob Harold wrote:
>
> If it gets an authoritative answer saying that there are no address
> records, then it should respect that answer. If that is incorrect, then
> whatever gave tha
r gave that answer is broken or misconfigured and should be fixed.
Perhaps I am missing something. In what cases can you imagine getting a
response with no errors and no records?
Perhaps a load balancer that has probed all the servers and determined that
none are working? If you want a fall-
d Evan Hunt for their imminent feedback.
>
> IIRC a directorate reviewer noted that "imminent" means "expected to
> arrive in the near future but not yet present"; such text does not seem
> appropriate for final publication since review after that point would
> not be helpful.
>
I think the word they wanted is "eminent".
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e. You could use a VPN
or buy a network service (even a dedicated line) for a higher price that
does not sell your data. Their network, their rules, but you choose the
network.
--
Bob Harold
> On Wed, Apr 3, 2019 at 15:26 Paul Vixie wrote:
>
>> i had to think about this for qu
ly if it has been
compromised."
3. Constructing a Server Cookie
"The Server Cookie is not required to be changed periodically if a
secure pseudorandom function is used."
I am not a cryptography expert, but the above sounds like the Client secret
and Server Cookie could be left forev
tively lengthened, by refusing to look them up again?
I think 'serve-stale' should focus on the situation where the auth server
is not available, and not change the handling of short ttl's. Or am I
mis-reading that?
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ub zone for this domain.)
>
I think in most solutions, if the name servers for "
malware-c-and-c-as-a-service.com" and "com" are both unreachable, the
domain should continue to resolve. But if "com" is reachable, and says "
malware-c-and-c-as-a-service.com&qu
On Fri, Feb 15, 2019 at 7:49 AM Arnt Gulbrandsen
wrote:
> On Thursday 14 February 2019 22:41:56 CET, Bob Harold wrote:
> > The draft assumes typical TTL is a week, but what I see in the root zone
> is:
> ...
>
> I hoped noone would notice. It's good rather than bad, overall,
2
4159 172800 A
3648 172800
3 172800 DNSKEY
7269 172800 NS
2 172800 RRSIG
13 518400 A
13 518400
13 518400 NS
1 518400 RRSIG
2903 86400 DS
1536 86400 NSEC
2926 86400 RRSIG
2 86400 SOA
1 <<>> 9.11.
her things that
answer DNS queries, like load balancers, should also return proper SOA and
NS records, not just A and AAAA records, for the same reasons.
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
nses)
Would that work? Should that be in the draft?
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Mon, Nov 5, 2018 at 9:01 AM Ladislav Lhotka wrote:
> On Mon, 2018-11-05 at 14:44 +0100, Normen Kowalewski wrote:
> > Hi Bob,
> >
> >
> > > On 12. Oct 2018, at 15:48, Bob Harold wrote:
> >
> > sorry for the very late reply; please allow
might never happen.
Another option to give users is a non-updating fallback A record, that
could point to a web redirect. That saves all the hassle of updates. (I
encourage users to redirect the apex to www... and the I CNAME www to the
CDN. Some users don't want the www, but it solves the DNS problem.)
My preference would be a *NAME record that specifies which record types it
applies to. So one could delegate A and at apex to a web provider, MX
to a mail provider, etc. That would also be valuable at non-apex names.
But I am happy to support ANAME as part of the solution.
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
danyork
>
> http://www.internetsociety.org/
>
>
Looks good to me. I have no strong opinion on where it should be
published. If published somewhere other than as an RFC, you might add some
current statistics on old versions of software in use and how many things
never get updates to
eport back
over time a summary of what it got, when it next pulls from its upstream,
eventually reaching the source. I don't have a good answer for that.
Perhaps the kinds of hacks we did for the root zone key reporting are
needed.
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Wed, Oct 24, 2018 at 5:49 AM Wessels, Duane
wrote:
>
> > On Oct 22, 2018, at 6:53 PM, Bob Harold wrote:
> >
> > Just my opinions:
> >
> > Keep the Reserved field
> >
> > Include occluded data - it is part of the zone, even if never served.
&
gt; A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-17
Page 6
"Early Data"
The last phrase:
"a TCP SYN message that does not use TLS
encapsulation but contains is not permitted."
Seems to be missing
they domain names but not valid
hostnames (see [RFC7719] for these definitions).
s/ they domain names / they are domain names /
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e, even if never served.
(Similar to glue data when a server has both a parent and child zone.)
If you might have multiple zonemd records not at the apex later, why not
allow them now? Otherwise, your choice whether to restrict them. (Someone
will find a use for them, like verifying glue records
ince serve-stale as proposed relies on recursion
> failing, if there was no attempted recursion that could have failed
> there will be no revisiting the cache to find stale answers.
>
Yes, that is worth mentioning, since some users won't imme
DNS NSAP Resource Records";
}
It seems odd to me to create the reference field as a string that contains
what looks like YAML, except that it has extra blank lines. Does YANG not
have a standard way to represent a list, and should the reference field
always be a list, for consistenc
On Fri, Oct 12, 2018 at 9:27 AM Dave Crocker wrote:
> On 10/12/2018 9:23 AM, Bob Harold wrote:
> > Sorry to ask this here, but looking at those links, I cannot find a
> > "diff" link anywhere. (I found it in the other emails, but would like
> > to know how to
but looking at those links, I cannot find a "diff"
link anywhere. (I found it in the other emails, but would like to know how
to get there from the pages above.)
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-fix-05
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-fix-05
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-fix-05
Minor nit:
The &quo
There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-13
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=d
versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-fix-04
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-fix-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attr
ion. In a DoH world, I cannot
imagine every third-party DoH provider giving our security group that
information. They will follow their own security measures, but will still
affect ours because we lose visibility.
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
if I transfer a
copy of the root (or other zone), I can verify the signed parts with
DNSSEC, and the glue by resolving them and verifying from the child zone.
Does that leave any unverified records (are glue the only unsigned records)?
Note that the child might have different records than the parent
ime looks like a good place to use
bittorrent. (Is that reasonable?) So the 'sources' will be untrusted, and
we do need some way to verify the resulting file that we get.
I like the XHASH idea, it seems to reduce the work required on each
update. But I would be ok with ZONEMD also.
--
Bob Harold
&g
et
>
Dot "." has special meaning in DNS, so I would prefer:
_ta-*
Not regex, but a common wildcard usage.
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.1. SRV Specification Changes
"The specification for a domain name under, which an SRV [RFC2782] resource
record appears, provides a template for use of underscored node names."
"under which" is a phrase that should not be broken with a comma. Perhaps:
"The specificatio
There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-12
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-12
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-12
>
As I understand it, there are cases where TCP is handled differently than
UDP. TCP has a session and is less susceptible to source address
spoofing, so things like "ANY" responses, or longer answers, might be
handled differently.
--
Bob Harold
On Mon, Jul 2, 2018 at 6:10 PM wrote:
&
with "was disabled or not implemented" or "was not
implemented or was disabled"
4. Sentinel Tests from Hosts with More than One Configured Resolve
"Resolve" -> "Resolver"
--
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
1 - 100 of 258 matches
Mail list logo
