[ Quoting in "Re: [DNSOP] Dnsdir early review of ..." ]
I wholeheartedly support the draft.
The only piece missing to make it *perfect* is "MUST use QDCOUNT=1",
or in other words, banning QDCOUNT=0 usage with DNS COOKIES. It's
unnecessary complexity.
yes, please, the amount of code that dupli
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
NSID.
"Resolver and forwarder behavior is undefined" is too weak IMO, and should
point to the
hop-by-hop nature for EDNS0 options, are explicitly sa
[ Quoting in "Re: [DNSOP] nsec3-parameters opinio..." ]
The document should strongly discourage any use of NSEC3
I would very much see a sentence/paragraph stating this in the document as well.
/Miek
--
Miek Gieben
___
DNSOP mailing
| accepts|
|--+---+|
| Peter van Dijk | 0 | anything low |
| Matthijs Mekking | 150 | 150 -- vendors implemented |
| Miek Gieben | 100 | or lower |
| Paul Vixie | 0 ||
| Vlad
would recommend against using a limit that happens to be in use at the
current time, and
would just use 100 (or even lower). Resolvers will continue to work fine and
can lower their
limit at their leisure.
/Miek
--
Miek Gieben
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
is used by cloudflare and who knows how many other projects. The PR speaks
of testing
against a Python implementation, so that _also_ has support for the older draft.
/Miek
--
Miek Gieben
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailma
I think making this document a standard would be a mistake.
I think NOT publishing this document at all would be a BAD thing.
I support adoption and will review and continue to agrue against standards
track.
+1 on what's said here.
/Miek
--
Miek G
ified. For these reasons, it is preferable to
secure the
data itself."
That looks like an implementation detail for nameservers loading the zone, not
something
the IETF should fix.
/Miek
--
Miek Gieben
___
DNSOP mailing list
DNSOP@ietf.or
[ Quoting in "Re: [DNSOP] SVCB wire format (draft..." ]
There are 0 or more sub TLV fields.
so, there equal when not specified and then diverge? I think the draft can be
more clear
in this regard. And maybe some text on why the TXT encoding wasn't choosen as
that seemed
to worked for SPF.
_
inal. For example,
there's still some active discussion about precisely how to represent the
contents of the SvcFieldValue (in ServiceForm).
What's the reason behind not reusing the TXT record? To free-form? Other issues?
/Miek
--
Miek Gieben
_
, these MUST then be ignored for the
presentation format (handwaving the actual text for the draft here a bit).
/Miek
--
Miek Gieben
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
I agree with Paul here. Also sidesteps questions like why HINFO is not in
this list.
On Mon, 13 May 2019, 09:08 Paul Hoffman, wrote:
> On May 13, 2019, at 3:00 PM, Evan Hunt wrote:
> >
> > On Mon, May 13, 2019 at 07:47:35AM +, Paul Hoffman wrote:
> >> A far easier approach is for any develo
[ Quoting in "Re: [DNSOP] Order of CNAME and A in..."
]
On Tue, Aug 11, 2015 at 08:12:20PM +0100, Miek Gieben wrote:
So this discussion stems from this issue:
https://github.com/skynetservices/skydns/issues/217
And apparently the glibc resolver assume this is ordering is in e
will authorative answer
for the (single) domain is has configured.
/Miek
--
Miek Gieben
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
izing *XFR.
/Miek
--
Miek Gieben
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[ Quoting in "Re: [DNSOP] NOTE RR type for
confid..." ]
On May 27, 2014, at 1:32 PM, Miek Gieben wrote:
[ Quoting in "[DNSOP] NOTE RR type for confidenti..." ]
http://www.ietf.org/internet-drafts/draft-hunt-note-rr-00.txt
Interesting idea!
What happens if a serv
records and doesn't know about NOTE
and treats them as unknown records?
IOW I wonder if you can ever enforce "can not get a response for a NOTE query"
and maybe you should just give up and allow for this (with TTL=0)?
/Miek
--
Miek Gieben
__
[ Quoting in "Re: [DNSOP] my dnse vision..." ]
> Francis,
>
> This is some good summarizing. With your solution, you don't mention
> UDP. I would consider the lack of UDP an issue with moving forward at
> least for wide deployment. Others seem to think otherwise.
>
> I'd be interested in heari
t; example.com. IN PARENT SOMERRTYPE rrtype-specific-data...
> > . . .
>
> +1
I like this approach too.
Grtz,
--
Miek Gieben http://miek.nl
signature.asc
Description: Digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[ Quoting in "Re: [DNSOP] Adoption of I know I'm late, but for what it's worth I'd support this.
+1
I've skimmed the document and support it being a wg doc. I also volunteer as
a reviewer.
Kind regards,
Miek Gieben
signature.asc
Descr
w insight and practices.
> It advises registries to store only DS in stead of DNSKEY material in
> their database.
The paragraph is a *suggestion* in a *bcp*. With the central point
being that a child can choose its hash. I think this is a too minor
point to (again) stop the AUTH48 proce
ra DNSKEY RRs - the same for both the
> old and the new operator. It does not require cross-signing as described
> in rfc4641bis, and it does not require either operator to host NS records
> pointing at a competitor.
Isn't this?
https://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-ch
[ Quoting in "Re: [DNSOP] I-D Action: draft-ietf-..." ]
> > While dnsop-dnssec-key-timing provides a fairly thorough
> > background which promotes understanding of the underlying issues,
> > it's still a thorny document to apply to an actual operational
> > event.
> >
> > I think it would be grea
23 matches
Mail list logo
