Re: [DNSOP] [dns-privacy] [core] WGA call for draft-lenders-dns-over-coap

[Alexander Mayrhofer]

Hello everyone,

Speking as the author of RFC 7830 – there was some discussion whether the 
document should say “SHOULD NOT” or “MUST NOT” when padding DNS packets over 
unencrypted packets. We couldn’t come up with any other use case (maybe except 
testing of the feature over unencrypted transport), so the consensus of the 
group was that we should be strict, especially as padding might be an easy way 
to bloat packets. I do agree that this connects DNS answer behaviour with 
transport choice – hence creates a dependency that’s probably not very wise in 
a protocol that has already pretty complex dependencies.

If the community believes that this requirement should be relaxed (and it’s 
worth the effort), I’m up for creating a revision of RFC 7830. This might also 
be a chance to step up EDNS Padding to Internet Standard – I think it’s widely 
deployed on billions of devices (Android..).

Thoughts?

Best,
Alex


Von: dns-privacy  Im Auftrag von Vladimír Cunát
Gesendet: Freitag, 9. September 2022 18:11
An: Ben Schwartz 
Cc: c...@ietf.org; DNS Privacy Working Group ; dnsop 
; Jaime Jiménez 
Betreff: Re: [dns-privacy] [DNSOP] [core] WGA call for 
draft-lenders-dns-over-coap

On 06/09/2022 17.06, Ben Schwartz wrote:
The choice of transport is independent of the DNS server's answering behavior, 
which must not be modified by the transport.

Nit: there's a very specific counter-example of EDNS padding which is meant to 
be added depending on transport encryption.  
https://www.rfc-editor.org/rfc/rfc7830#section-6

There might be some others (in future, too), as encryption does change some 
considerations, but yes - not basic stuff like following CNAMEs.

--Vladimir | knot-resolver.cz
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] NSEC3 Guidance - zone size impact of opt-out

[Alexander Mayrhofer]

Wes, all,

thanks for putting together draft-ietf-dnsop-nsec3-guidance. I have
one small comment regarding section 2.2 (Flags):

In some deployments of larger (eg TLD), in-memory zone size on the
authoritative servers is a significant issue, particularly if the
total memory size required is multiplied by hundreds of anycast nodes.
Opt-out for such zones with sparse DNSSEC deployment can make a big
operational / cost difference there. Maybe that aspect should be
included in the document.

thanks!
Alex

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] On .ZZ

[Alexander Mayrhofer]

Setting the basic issue aside (I'm still a bit torn) I agree with
Warren that it would need a string that has a meaning.

..ZZ would remind me of long beards and loud motorcycles for the rest
of my life.. https://de.wikipedia.org/wiki/ZZ_Top

best,
Alex

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] ROOM CHANGE to TYROLKA - Security/Registry Lock Side Meeting: Wed, 14:00 - 15:00

[Alexander Mayrhofer]

Hello everybody,

(sorry for crossposting, but the side meeting was mentioned during today's 
dnsop session).

I was able to organize a bigger room - the meeting will be held in TYROLKA. 
Date and Time remain unchanged (Wed, 2019-03-27, 14:00-15:00)

Thanks & enjoy your evening,
Alex


Von: Alexander Mayrhofer
Gesendet: Dienstag, 26. März 2019 11:13
An: reg...@ietf.org
Betreff: Security/Registry Lock Side Meeting: Wed, 14:00 - 15:00, Room Paris

Hello everyone,

as mentioned during the regext WG session, i've organized a "SecurityLock / 
RegistryLock" side meeting. Meeting details are as follows:


-  Date: Wed, 2019-03-27

-  Time: 14:00 - 15:00

-  Location: Room "Paris" at the IETF venue

Unfortunately, remote participation won't be possible. I do understand that a 
beamer is available, though.

My plan for the Agenda would be as follows:


-  Security Lock / Registry Lock "problem space" introduction (Alex, 
10m)

-  Tour de Table of current/planned "Security Lock" features, brief 
description (2m each), eg:

o   How does the locking work (Who locks, how?)

o   How does the "approval" of changes work (Who approves, what happens to 
transactions?)

o   How does the "unlocking" work (Who unlocks, and how?)

o   Forms of authentication

-  Which areas could benefit from standardization? Discussion (20m)

-  Wrapup and next steps (10m)

I'm looking forward!

Best,
Alex
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Din] Fwd: New Version Notification for draft-mayrhofer-did-dns-01.txt

[Alexander Mayrhofer]

On Fri, Feb 15, 2019 at 8:47 PM Melinda Shore
 wrote:
> I think the question of whether or not to provide
> decentralized identifiers and whether or not this proposal
> delivers on the "decentralized" claim is out of our hands,
> as the core spec (which has a lot of additional problems)
> comes out of the W3C.  I think the IETF's involvement is
> probably limited to their use of DNS in the resolution
> process.

I do agree. We provide the "link" from an IETF protocol to a protocol
developed in another SDO.

> p.s. and it's probably worth pointing out that this work is
> being done in a W3C community group, so until it looks like
> it's actually going to be published as a WC3 spec I'm not
> sure I'd like to see IETF working group resources being
> spent on this.

Yes, exactly, this is a community group work right now. However, i do
understand that the "upgrade" to a working group is currently
underway.

best,
Alex

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Din] Fwd: New Version Notification for draft-mayrhofer-did-dns-01.txt

[Alexander Mayrhofer]

Paul,

On Fri, Feb 15, 2019 at 7:47 PM Paul Wouters  wrote:
> I think this document should be Experimental and not Standards Track?

I was torn when i did the first revision of this. I think it depends
on the stability of Decentralized Identifiers themselves. Once that
schema becomes widely used, i think any protocol that connects the DNS
and DIDs should be Standards Track. But i leave that up to "higher
forces" as soon as i find a suitable "home WG" for that.

> The reference to 7929 should be normative, not informative, since
> you actually need to read a secion of 7929 to implement this document.

Agreed. I've considered replacing the "instruction diff" to OpenPGP
with a full description in the document itself. The idea to use that
scheme in email came in quite late before i wrote -00, so that section
also reflects some laziness. With the "two label" hierarchy introduced
in -01, i think a full description would be better anyways. Well do so
in -02. Which, in turn, would allow the 7929 reference to stay
informative.

> I'm not sure if one should use _did.example.com for host names and
> _mailto._did.example.com for email addresses. I would keep that at
> the same level, eg:
>
> _hostname._did.example.com
> _mailto._did.example.com

I'd love to have a discussion about semantics of both options at some
point. Maybe we can do a short meeting during IETF104? I know there
are many ways to do that, and personally i'm not sure which way would
be the "right" one.

> This technically also allows one to separate the two DNS zones more
> clearly (and could even be managed by a different group)

Yep, introduces a zone cut. Then again, i'm not sure what (if we
introduce that schema above) the semantics of a record right unter
_did would be.. Or would that be disallowed?

> I'm really on the fence for this document. On the one hand, it is good
> to have a memorable decentralized identifier, but on the other hand if
> you rely on DNS (and DNSSEC), is this identifier really still
> decentralised in the "we don't trust the USG or Verisign" way ?

The identifier is still fully decentralized, the method of discovery
probably not. I've also heard that from folks from the Self Sovereign
Identity community... However, they are seeking ways for people to
discover DIDs. Commonly used are QR codes, but everyone is aware that
replacing the QR code on an ATM machine would create an easy of "real
world" phishing, so other methods of discovery are definitely worth
investigating.

> I guess if you interpret it as a migration strategy away from DNS, it is okay.

Note that we could also create a "full loop" of verification. The DID
document published behind a DID could include a link back to the
domain name. I've not investigated that further, though, but it's an
interesting area.

So, would you be interested to discuss this in Prague?

best,
Alex

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-mayrhofer-did-dns-01.txt

[Alexander Mayrhofer]

Stephane, all,

[I feel cautious about continuing to cross-post this to dnsop as well
as dinrg - however, it does apply to both areas, so i'll keep both
groups in for now]

On Fri, Feb 15, 2019 at 10:37 AM Stephane Bortzmeyer  wrote:
> I think that it is an important work because it brings the power of
> the DNS to many other identifier systems. So, I support it.

Thanks - great to hear. I'm hearing that DIDs are being used in more
and more situations, so i think it makes sense to define that
"bridging" protocol between the two "worlds.

> May be more examples could help people figure out the use cases? "My
> Bitcoin address is at foobar.example" and then the Bitcoin software
> would query _did.foobar.example and get
> .

I will add more examples in the next revision. We also need to include
an example for the "email address" use case.

> I note that there exists already non-standard (and probably not really
> deployed) solutions in that space, some specific to a TLD
> 
> 

I'm aware of the .luxe initiative, however, i haven't yet seen any
technical specifications about how the connection between DNS and
Blockchains is performed. If anybody has a pointer, i'd definitely
appreciate it.

The other alternative proposal i've found is https://openalias.org/ -
scroll down for their definition of the TXT record. They don't use
DIDs as far as i understand, though.

> Regarding draft -01: it seems OK to me. The only problem I find:
>
> > particularly the concerns around downgrade attacks when the record
> > is not signed
>
> Why downgrade attacks specifically? Without DNSSEC, a lot of attacks
> are possible.

I agree, that section requires some rewording. I'm referring to the
language in the OpenPGP DANE RFC here. I'm happy to work on more text,
and open to suggestions :)

best,
Alex

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-mayrhofer-did-dns-01.txt

[Alexander Mayrhofer]

FYI,

i've submitted a new revision of the DID-DNS draft (publishing
Decentralized Identifiers in the DNS). The major changes in this
revision are:

- The registration for the _did Label is now performed via the Global
Underscore Name registry (see draft-ietf-dnsop-attrleaf, currently in
RFC editor queue)
- The experimental "email" method uses _mailto._did as scope selector
(rather than plain _did). This allows for clean seperation of other
future services using the scheme.

Feedback highly appreciated,
Alex

-- Forwarded message -
From: 
Date: Fri, Feb 8, 2019 at 2:52 PM
Subject: New Version Notification for draft-mayrhofer-did-dns-01.txt
To: Dimitrij Klesev , Alexander Mayrhofer
, Markus Sabadello




A new version of I-D, draft-mayrhofer-did-dns-01.txt
has been successfully submitted by Alexander Mayrhofer and posted to the
IETF repository.

Name:   draft-mayrhofer-did-dns
Revision:   01
Title:  The Decentralized Identifier (DID) in the DNS
Document date:  2019-02-08
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-mayrhofer-did-dns-01.txt
Status: https://datatracker.ietf.org/doc/draft-mayrhofer-did-dns/
Htmlized:   https://tools.ietf.org/html/draft-mayrhofer-did-dns-01
Htmlized:   https://datatracker.ietf.org/doc/html/draft-mayrhofer-did-dns
Diff:   https://www.ietf.org/rfcdiff?url2=draft-mayrhofer-did-dns-01

Abstract:
   This document specifies the use of the URI Resource Record Type to
   publish Decentralized Identifiers (DIDs) in the DNS.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] draft-ietf-dnsop-attrleaf vs. RFC7553

[Alexander Mayrhofer]

Hello everyone,

I'm turning my head around an issue around the attrleaf draft, and its 
connection with RFC7553 (the URI RRType). Im specifically wondering what the 
connection between the "service parameter" in RFC 7553 and the "Global 
Underscore Node Names" in draft-ietf-dnsop-attrleaf is.  I'm trying to reword 
draft-mayrhofer-dns-did to request a new underscore node name. My issues is as 
follows:

RFC 7553 restricts the  "service parameters" (those underscored names) as 
follows:


   Valid service

   parameters are those registered by IANA in the "Service Name and

   Transport Protocol Port Number Registry" 
[RFC6335] or as "Enumservice

   Registrations [RFC6117].

However, I understand the intent of draft-ietf-attrleaf (as far as I 
understand) is to replace/extend that definition by a new registry, and does 
indeed include underscore node names for the URI RRType in Section 4.3. 
However, I'm wondering whether that formally "overrides" the previous 
specification.. So, my questions are:


A)  Would it be enough to request a global underscore node name to use it 
with the URI RRType

B)  And shouldn't draft-ietf-dnsop-attrleaf hence UPDATE RFC7553?

(I know the draft is already *very* well advanced in the process, so I'm 
opening a can of worms here - but better late than never? And there are 
definitely more future use cases for URI records that might be well covered by 
the attrleaf document..)

Comments appreciated!

Best,
Alex

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] IETF 103: Call for agenda items

[Alexander Mayrhofer]

Hello Benno,

I'd like to talk about
https://tools.ietf.org/html/draft-mayrhofer-did-dns-00. I think i
should be good with 5 minutes.

much appreciated!
Alex

On Tue, Oct 2, 2018 at 11:15 PM Benno Overeinder  wrote:
>
> Hi all,
>
> We have requested one DNSOP session of 2 hours for the IETF 103.  The
> preliminary IETF agenda will be published on October 5th.
>
> Please submit a request for agenda time if you want to present a draft.
> We will be following up on several items, but there is also room for new
> work.
>
> Thanks,
>
> Your DNSOP chairs
> (Suzanne, Tim and Benno)
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-mayrhofer-did-dns-00.txt

[Alexander Mayrhofer]

All,

I've just submitted an individual draft on how to publish
"Decentralized Identifiers" (DIDs) in the DNS. DIDs is an addressing
scheme for resources on distributed ledgers, such as blockchains (Oh
no he said the B-word!). They use a provisional URI scheme ('did'),
and are specified in the W3C Community Group here:
https://w3c-ccg.github.io/did-spec/

We do believe it has minimal impact on the DNS Camel, as this is
essentially a new use case for an existing RRType ("URI") with only
minimal additional specification (and that additional specification
sits on the application level).

Bring on the torches & pitchforks! ;)

best,
Alex

P.S.: I'm cross-posting this on dinrg as well - it sort of sits
"between" those two groups



-- Forwarded message --
From:  
Date: Tue, Aug 7, 2018 at 8:40 AM
Subject: New Version Notification for draft-mayrhofer-did-dns-00.txt
To: Dimitrij Klesev , Alexander Mayrhofer
, Markus Sabadello




A new version of I-D, draft-mayrhofer-did-dns-00.txt
has been successfully submitted by Alexander Mayrhofer and posted to the
IETF repository.

Name:   draft-mayrhofer-did-dns
Revision:   00
Title:  The Decentralized Identifier (DID) in the DNS
Document date:  2018-08-06
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-mayrhofer-did-dns-00.txt
Status: https://datatracker.ietf.org/doc/draft-mayrhofer-did-dns/
Htmlized:   https://tools.ietf.org/html/draft-mayrhofer-did-dns-00
Htmlized:   https://datatracker.ietf.org/doc/html/draft-mayrhofer-did-dns


Abstract:
   This document specifies the use of the URI Resource Record Type to
   publish Decentralized Identifiers (DIDs) in the DNS.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

[Alexander Mayrhofer]

> I'm not particularly arguing either way on this question of signalling,
> but do we have any feel for how many stubs ever send EDNS?
>
> libresolv can do it, and getdns does, but I don't think glibc's resolver
> routinely sends EDNS.

Ray,

i do agree - having figures "from the field" about this would be
great. We don't see much direct stub resolver traffic obviously, so i
can't provide any, unfortunately..

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

[Alexander Mayrhofer]

On Wed, Nov 15, 2017 at 9:57 AM, Dave Lawrence  wrote:
> I personally am of the belief that yes, if the request has an OPT then
> a responder can include an option code that was not in the request.
> At least I don't see anything in 6891 to prohibit it.  This is
> behaviour that draft-ietf-dnsop-extended-error is also expecting.

I agree that signaling is important, and i also believe that if
there's an OPT in the request, we can safely assume that the client
would not choke on this option. I'm torn on the question whether or
not stale data should be served (without signaling, in that case) when
the request does *not* contain an OPT request. Probably we should err
on the side of *not* serving stale when a client is not "EDNS
capable", because that would mean no change from current behaviour.

Alex

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-mayrhofer-edns0-padding

[Alexander Mayrhofer]

George,

i certainly agree. Noted for a revision.

Alex

Von: George Michaelson [mailto:g...@algebras.org]
Gesendet: Donnerstag, 23. Juli 2015 18:52
An: Alexander Mayrhofer
Cc: dns-priv...@ietf.org; dnsop@ietf.org
Betreff: Re: [DNSOP] draft-mayrhofer-edns0-padding

What does it mean to exceed the proffered EDNS0 buffer size with your padded 
response?

You're 'silent' on length, but surely the server should respect the EDNS0 size 
proffer as a limit?

On Thu, Jul 23, 2015 at 6:50 PM, Alexander Mayrhofer 
alexander.mayrho...@nic.atmailto:alexander.mayrho...@nic.at wrote:
Hi,

I had a discussion with Daniel Khan Gillmor today, and we talked about his 
proposal to specify a padding option in TLS so that message-size based 
correlation attacks on encrypted DNS packets could be prevented. We  continued 
discussing other options (such as artificial RRs in the additional section), 
and I floated the idea that we could use EDNS0 to include padding in DNS 
packets.

So, I've created a quick-and-dirty strawman proposal draft for this idea, and 
i'm happy to discuss this during tomorrow's DPRIVE session if we have time:

https://www.ietf.org/id/draft-mayrhofer-edns0-padding-00.txt

Bring out the pitchforks and torches :)

Alex

___
DNSOP mailing list
DNSOP@ietf.orgmailto:DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] draft-mayrhofer-edns0-padding

[Alexander Mayrhofer]

Hi,

I had a discussion with Daniel Khan Gillmor today, and we talked about his 
proposal to specify a padding option in TLS so that message-size based 
correlation attacks on encrypted DNS packets could be prevented. We  continued 
discussing other options (such as artificial RRs in the additional section), 
and I floated the idea that we could use EDNS0 to include padding in DNS 
packets.

So, I've created a quick-and-dirty strawman proposal draft for this idea, and 
i'm happy to discuss this during tomorrow's DPRIVE session if we have time:

https://www.ietf.org/id/draft-mayrhofer-edns0-padding-00.txt

Bring out the pitchforks and torches :)

Alex

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of edns-tcp-keepalive-01

[Alexander Mayrhofer]

 * PROTOCOL: Is the expected behaviour (MUST) from both client and server
 that they should add the Option to every single request / response during a
 keepalive session? Please clarify the intended behaviour..

Two final comments, sorry:

* EDITORIAL/PROTOCOL: Shouldn't the option (as well as the draft) be renamed 
from keepalive to timeout? To my understanding keepalive would refer to a 
mechanism where empty, ping style packets would be used to keep the session 
established, and be misleading for a mechanism to negotiate timeout values... 
change to edns-tcp-timeout Option, and according draft name?

* PROTOCOL: Are there any race conditions when this Option is used in 
conjunction with Ray's Connection Close flag 
(https://tools.ietf.org/html/draft-bellis-dnsop-connection-close-00)? 

Alex

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Review of edns-tcp-keepalive-01

[Alexander Mayrhofer]

Hi,

I've reviewed the keepalive draft. Generally, i do like the concept a lot 
because:  a) there's certainly a use case that covers real operational issues  
b) it's a space-efficient and c) unobstrusive. However, i think the document 
could improve on clarity in certain aspects - see below for details. I've 
tagged  my feedback with NIT, EDITORIAL, PROTOCOL to indicate severity 
levels of the comments. 

* EDITORIAL: I think the Abstract could be cut down to the first sentence of 
the second paragraph. Everything else should go into (or is already a copy of) 
the Introduction section. Personal taste, i know, but i like short, to the 
point abstracts.

* NIT: API is not expanded on first use

* EDITORIAL: The second paragraph on page 4 lists DNSSEC and crypto-related 
RRTypes as the culprits for the prevalence of truncated responses. However, it 
misses the main point that increased response sizes are the primary problem. So 
changing the text into something The increasing size of response packets, (for 
example due to deployment of DNSSEC and crypto-related RRTypes)...  would be 
better.

* EDITORIAL: Mention somewhere that the re-use of TCP connections to 
nameservers would even benefit more in case DNS over TLS would be introduced. 
(Sidenote: From the architectural perspective, i think a TLS-DNS spec should 
actually  REQUIRE  a TLS enabled DNS client to support the Keepalive option)

* PROTOCOL: I'm missing a normative and clear definition of how to interpret 
TIMEOUT values. The Option format says a timeout value for the TCP 
connection (which is way underspecified, given the various timeouts in TCP). 
3.2.1 on the other hand says it's representative of the minimum expected time 
an individual session should remain established for it to be used... (Which i 
interpret as the absolute session duration from the time of establishment) - 
other sections of the document make me believe it's the maximum interval 
between two subsequent queries ...

That needs to be fixed, because it will cause interop problems if not clearly 
defined. My proposal would be that the TIMEOUT is the maximum interval a client 
can use that TCP connection since it received the last  DNS message from the 
other end (i don't consider 1/2 RTT here as relevant). 

The document should also clarify the relation between those application level 
keepalive mechanism and TCP level keepalives - i do understand there's no such 
relation - which should be mentioned.

Also, please clarify that TIMEOUT is unsigned...

* PROTOCOL: Are the TIMEOUT values (whatever  time interval they define, see 
above) negotiated for a single session only, or do they affect *all* TCP DNS 
sessions to a specific IP address? Since there is no session for the UDP part 
of the negotiation, the client's first assumption would be it's per IP address. 
However, as soon as the TCP sessions are established, the TIMEOUT 
(re-)negotiation could differ for each individual session? A short 
clarification would be good - i think the TIMEOUT value should be independent 
for each individual TCP session.

* EDITORIAL: 3.2.2, second paragraph: The main point is missing in the second 
sentence, i suggest adding   MAY keep the existing TCP session open, *up 
to the duration indicated in the TIMEOUT value of the response.*

* PROTOCOL: Is there any way to signal to a client that it should stop using 
the session as soon as possible, because the server wants to tear it down 
immediately? Since 0 is currently reserved for infinitely long sessions, that 
is not an option. A value of  1 would allow the client to continue using the 
session for another second, wich is suboptimal (and could impact several 10k's 
of packets on busy servers...) - So, i do suggest re-considering the semantics 
of the 0 (maybe use 65535 as infinity and add text that a value of 0 
should indicate teardown immediately - that would be more logical to me?)

* PROTOCOL: Is the expected behaviour (MUST) from both client and server that 
they should add the Option to every single request / response during a 
keepalive session? Please clarify the intended behaviour..

-  If Yes: what is the expected behaviour in case a subsequent packet does not 
include that option? Keep going until TIMEOUT, or assume that the server 
suddenly doesn't want to do keepalive anymore, and revert to dumb behaviour? 
- If No: My assumption would be that after the TIMEOUT is inititally 
negotiated, client/server would keep counting, no matter whether messages 
continue the option. Only once the TIMEOUT approaches, a single packet would 
refresh the TIMEOUT?

Personally, i tend towards No, because sending the information in each and 
every message seems redundant to me (updating session timers on each single 
packet).. Feedback appreciated :)


tia,
Alex

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Session to discuss DNS Privacy et. al.

[Alexander Mayrhofer]

Tim,

 We have decided after much discussion (and little negative feedback) to hold
 a seperate session Thursday Evening at 16:40 to discuss DNS privacy and all
 the things that come with it.

Is that the correct time? The Agenda does list time slots starting at either 
17:00 or 18:40 - are you sure you don't mean 18:40?

thanks for clarification,
Alex


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] DS without NS in a delegation?

[Alexander Mayrhofer]

Hi,

We've been discussing internally whether or not including DS records into a 
zone without respective NS record(s) makes any sense (assuming that there are 
no other RRSETs for the respective label in the zone itself - pure delegation 
scenario)... My personal assumption is that it does not, since the DS record 
can never be used to verify the information in the (unreachable) delegated 
zone? 

On a related (although slightly off topic) issue, we were also assuming that 
EPP status values serverHold as well as clientHold do affect both NS as 
well as DS records.

Comments appreciated.

thanks,
Alex Mayrhofer

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt

[Alexander Mayrhofer]

 You may be quite right about that. It's one of the things that I want
 to have a discussion about. I started out with a somewhat conservative
 specification, to see where the discussion will take us.
 
 More voices?

I would keep the ABNF to purely *technical* limits as well. Don't let
the ABNF preclude any policy decisions.

Alex
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Review of draft-ietf-dnsop-respsize-10

[Alexander Mayrhofer]

Hi,

I've volunteered in Philly to do a review of the response size drafts -
i have seperated my comments into content and nits issues. 

content
---

- The first sentence in 2.1 should probably start with A positive
delegation response.. because a negative response could for example
also include a SOA RR in the Authority section.

- In 2.2, there is some redundancy about the importance of zone
reachability by all IP protocols in common use. There are two almost
identical sentences about this in the third paragraph (although one of
them says should while the other says it's important to ensure). I
suggest removing one of those sentences.

- In 2.3, i'd suggest changing the first sentence of the last paragraph
into If any 'necessary' content cannot be fit...  instead of  .. is
not able to fill in.. - at least to me that would be more clear.

- I wonder whether 2.3 should include some text suggesting that the
preference of A vs.  records could also depend on the transport
protocol over which the query was received? At first glance, it would
make more sense to prefer  records in the additional section if the
query itself was received via IPv6, and prefer A records if the query
was received over IPv4? I haven't looked into more detail regarding
this, though.

- I have really a hard time understanding the last paragraph of Section
4. It might be me, but i can't grasp what this paragraph intends to say.


Nits


the online idnits checker reports a few issues - it complains about the
GTLD-SERVERS and ROOT-SERVERS domains, and the associated IP addresses.
However, i guess that it would not make much sense to change those
special domain names into example.com (i think it is clear from the
purpose of the document, too)

I found a couple of acronyms that are neither on the RFC editors well
known list nor expanded / referenced anywhere in the document. Those
include EDNS, RRset, CNAME, DNAME, RRs.

I'm missing a ToC (although i know it's not required, i'd appreciate
one).

Section 1 (Introduction) contains just one subsection (1.1 Introduction
and Overview). I suggest removing the sub-section title, and probably
changing the Title of section one into Introduction and Overview, if
desired.


that's all i found --

cheers

Alex
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-ietf-dnsop-respsize-10

[Alexander Mayrhofer]

 that's all i found --

hm. i knew i forgot something:

References: I guess that most of the Normative References in the draft
could be made Informative. The only normative ones i see are RFC1034,
RFC1035, and RFC2181. The others should be moved to an Informative
References section.

thanks,

Alex
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] DNS text in Enumservices guide...

[Alexander Mayrhofer]

As mentioned in the session today, the Enumservices Guide contains some
text on DNS Considerations in section 5.7:

http://tools.ietf.org/html/draft-ietf-enum-enumservices-guide

The original reason for this text was the unused Enumservice, which
conveyed assumptions about the DNS space below the record. Suggestions
for changes (or more extensive) text are appreciated.

Alex
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop