Re: [DNSOP] Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

[Tim Wicinski]

Michael

We talked it over and if there was a process fail, it's easier to fix now
then later. I already reached out to the AD who is stepping in for Warren
to hold off for now.

Let this be a Working Group Last Call on
draft-ietf-dnsop-rfc5011-security-considerations.
This will go from now until the end of the IETF next Friday.

The Current Intended Status is: Standards Track

We will be take comments on the changes now, and as well as during the
session on Wednesday.


Tim

On Mon, Jul 9, 2018 at 12:05 PM, Michael StJohns 
wrote:

> Tim/Suzanne -
>
> Please cancel the request for publication until you complete the WGLC for
> this document.
>
> The last WGLC for the document was October of last year - it failed on 28
> October https://www.ietf.org/mail-archive/web/dnsop/current/msg21225.html.
> No WGLC has been made since then.
>
> The consensus referenced in the shepherd's report was meeting consensus -
> not mailing list consensus AFAICT.  Specifically, I'd like to see if Ed's
> removed his objections.  I don't have a problem with the WGLC being used to
> judge consensus - but that's not what happened here.
>
> Later, Mike
>
>
>
> On 7/6/2018 9:08 PM, Michael StJohns wrote:
>
>> On 7/6/2018 8:13 PM, Tim Wicinski wrote:
>>
>>> Tim Wicinski has requested publication of 
>>> draft-ietf-dnsop-rfc5011-security-considerations-12
>>> as Proposed Standard on behalf of the DNSOP working group.
>>>
>>> Please verify the document's state at https://datatracker.ietf.org/d
>>> oc/draft-ietf-dnsop-rfc5011-security-considerations/
>>>
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>
>> *sigh*
>>
>> Point of order:  Did I miss the final WGLC on this after this last
>> version was published?  I can't actually find anything in the DNSOP
>> archives and I don't remember seeing the call.   So I'm suggesting that
>> we've missed a required stage.
>>
>> With respect to the shepher's writeup:
>>
>> 1) The first reference in the shepherd's write-up  is wrong - its
>> pointing to a whole other set of discussions related to Joe Abley's ideas.
>> 2) The second reference isn't representative of the actual discussion,
>> but only shows the point at which I got worn down. Please include a
>> reference that actually shows the attempts to try and resolve my issues.
>> 3) This document should not be a Proposed Standard as it documents
>> nothing implementable (that is nothing implementable in a computer), but is
>> operational guidance for the publication process.
>> 4) Is it usual for the WG chair to write the shepherd's report?
>> Specifically, it seems a conflict of interest for items (3) -(6).
>> 5) The technical summary is misleading.  This is not an update to 5011,
>> but guidance to the zone publisher who may have not understood the
>> implications of operational choices (e.g. steady state single trust anchor
>> vs 5011s recommendation of multiple trust anchors). E.g. "RFC5011 DNSSEC
>> Key Rollover Strategy" isn't a document referenced by this document, and
>> that would be the document that would be in need of an update.
>> 6) Same comment - it's not an update to the 5011 timers, but to the
>> understanding of the publishers of such zones that use 5011.
>> 7) Please include references of the emails of the "root server community"
>> review - AFAICT, Ed Lewis was the only one to comment on the list and the
>> last comment was last year.
>>
>> Mike
>>
>>
>> Mike
>>
>>
>>
>>
>>
>>
>>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Driu] Resolverless DNS Side Meeting in Montreal

[Patrick McManus]

this is essentially a bar bof - though lacking in a bar and I'm fond of
more professional terms so I call it a side meeting. It has no standing. If
you're interested then please come, if you're not or are conflicted then
you're missing anything process wise.

Someday it might graduate to becoming a bof - but I would never put a bof
forward that didn't have a proposal I was comfortable with. This is indeed
a side meeting for anyone interested to see if there is a shared vision for
what such a proposal might look like.

Its not in scope for any wg as there isn't a proposal. Its quite possible
that it might have multiple outcomes which are in scope for multiple
application groups; I've tried to cc the likely suspects here.  But that is
presupposing outcomes.

-P



On Mon, Jul 9, 2018 at 10:55 PM, Ted Lemon  wrote:

> This sounds an awful lot like an unapproved bof. The reason we don’t do
> those is that they tend to make it hard for people to participate. Why
> isn’t this in scope for dnsop?
>
> On Mon, Jul 9, 2018 at 10:49 PM Patrick McManus 
> wrote:
>
>> Hi All,
>>
>> I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in
>> Montreal.
>>
>> We have often talked about the benefits and concerns of DNS information
>> obtained from sources that are, shall we say, less globally trusted than a
>> recursive a resolver. The central use case is DoH when pushed from an
>> endpoint that isn't a recursive resolver but there have been other
>> proposals.
>>
>> For example www.example.com pushes you a  record for img1.example.com.
>> Should you use it? What if it is for img1.img-example.com ? Do the
>> relationship between these domains matter? What kind of relationship (i.e.
>> it could be a domain relationship, or in the context of a browser it might
>> be a first-party tab like relationship, etc..)? What are the implications
>> of poison? Trackers? Privacy of requests never made? Speed? Competitive
>> shenanigans or DoS attacks?
>>
>> This was out of scope for DoH.
>>
>> *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to
>> 17:30 on Monday July 16th.*
>>
>> This is a meeting of interested folks looking to see if we can agree on
>> next steps - we're not going to work out the details (nor should a side
>> meeting try and do so). so we'll have a tight agenda that I suggest
>> organizaing as follows:
>>
>> 1] What forms of transport could be in scope? HTTP/2 push is one such
>> vector, but I've heard others. Spray paint for example.
>>
>> 2] What needs to be considered when using such data? (signatures? scope?
>> etc?)
>>
>> 3] Who are the stakeholders for 1 + 2?
>>
>> 4] Is there enough interest to explore further? Next steps as output
>>
>> I hope you can come!
>>
>> -Patrick
>>
>> ___
>> DRIU mailing list
>> d...@ietf.org
>> https://www.ietf.org/mailman/listinfo/driu
>>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Driu] Resolverless DNS Side Meeting in Montreal

[Ted Lemon]

This sounds an awful lot like an unapproved bof. The reason we don’t do
those is that they tend to make it hard for people to participate. Why
isn’t this in scope for dnsop?

On Mon, Jul 9, 2018 at 10:49 PM Patrick McManus 
wrote:

> Hi All,
>
> I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in
> Montreal.
>
> We have often talked about the benefits and concerns of DNS information
> obtained from sources that are, shall we say, less globally trusted than a
> recursive a resolver. The central use case is DoH when pushed from an
> endpoint that isn't a recursive resolver but there have been other
> proposals.
>
> For example www.example.com pushes you a  record for img1.example.com..
> Should you use it? What if it is for img1.img-example.com ? Do the
> relationship between these domains matter? What kind of relationship (i.e..
> it could be a domain relationship, or in the context of a browser it might
> be a first-party tab like relationship, etc..)? What are the implications
> of poison? Trackers? Privacy of requests never made? Speed? Competitive
> shenanigans or DoS attacks?
>
> This was out of scope for DoH.
>
> *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to
> 17:30 on Monday July 16th.*
>
> This is a meeting of interested folks looking to see if we can agree on
> next steps - we're not going to work out the details (nor should a side
> meeting try and do so). so we'll have a tight agenda that I suggest
> organizaing as follows:
>
> 1] What forms of transport could be in scope? HTTP/2 push is one such
> vector, but I've heard others. Spray paint for example.
>
> 2] What needs to be considered when using such data? (signatures? scope?
> etc?)
>
> 3] Who are the stakeholders for 1 + 2?
>
> 4] Is there enough interest to explore further? Next steps as output
>
> I hope you can come!
>
> -Patrick
>
> ___
> DRIU mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/driu
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Resolverless DNS Side Meeting in Montreal

[Patrick McManus]

Hi All,

I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in
Montreal.

We have often talked about the benefits and concerns of DNS information
obtained from sources that are, shall we say, less globally trusted than a
recursive a resolver. The central use case is DoH when pushed from an
endpoint that isn't a recursive resolver but there have been other
proposals.

For example www.example.com pushes you a  record for img1.example.com.
Should you use it? What if it is for img1.img-example.com ? Do the
relationship between these domains matter? What kind of relationship (i.e.
it could be a domain relationship, or in the context of a browser it might
be a first-party tab like relationship, etc..)? What are the implications
of poison? Trackers? Privacy of requests never made? Speed? Competitive
shenanigans or DoS attacks?

This was out of scope for DoH.

*We'll do the meeting over 1 hour in the Dorchester room from 16:30 to
17:30 on Monday July 16th.*

This is a meeting of interested folks looking to see if we can agree on
next steps - we're not going to work out the details (nor should a side
meeting try and do so). so we'll have a tight agenda that I suggest
organizaing as follows:

1] What forms of transport could be in scope? HTTP/2 push is one such
vector, but I've heard others. Spray paint for example.

2] What needs to be considered when using such data? (signatures? scope?
etc?)

3] Who are the stakeholders for 1 + 2?

4] Is there enough interest to explore further? Next steps as output

I hope you can come!

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

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[George Michaelson]

What I want is the nexus of OOB "file" form zone download and
integrity check which is cheap to implement signer and receiver.

I was on PGP. Duane has taken me to an RR which is a sequenced,
canonicalized digest, which then is under the ZSK sign of the zone.

For the root, it feels doable. For Com, nothing but a
cipher-block-chain model of intermediates is going to scale but a
single file download and integrity check was always going to fail
there.

I know you're talking in-band download: I am targetting out of band
"file" download. Its a model. It works. Its useful. The least
dependencies and easiest path is what I seek, Olafur drove to a new
keying regime and external signatures. Duane has taken me back to "you
can use what you have, if you will canonicalize the file to make the
RR for a digest"

-G

On Tue, Jul 10, 2018 at 12:01 PM, Mark Andrews  wrote:
>
>
>> On 10 Jul 2018, at 10:22 am, George Michaelson  wrote:
>>
>> Yea, having read things properly and been hit by a cluestick I think
>> this is good.
>>
>> * the RR is a digest over canonicalized state
>>
>> * there is a simple method to take zone, re-canonicalize (its the
>> DNSSEC order) and check the digest
>>
>> * since the RR is covered by the ZSK signing, the entire zone is
>> understood to be in the state the publisher had when they made the
>> digest.
>>
>> * if you download a zone file, with this RR, you can re-canonicalize
>> and check easily.
>>
>> You have to have a DNSSEC ta over the keys used come what may, but
>> this looks like a mechanism which given an out of band TA has no
>> in-band DNS dependency to get a zone and check a zone.
>>
>> So functionally, Duanes thing is identical in outcome to PGP signing
>> or other exterior file signatures.
>>
>> -G
>
> The problem with what is currently there is that it requires the *entire* 
> zone to walked on every dynamic update to recompute the hash.  That has 
> always been the primary objection to SIG(AXFR).
>
> We can do the hashing (and signing) on much smaller increments.
>
> We could sign each RRset that is not already signed (GSIG) in the zone and 
> introduce a glue NSEC like record (GSEC) to prevent those RRsets being 
> removed.
>
> We could hash larger collections of RRsets but smaller than a the whole zone. 
>  That is what XSIG that I proposed earlier does.  It hashes the currently 
> unsigned zone data and prevents its removal from the zone.  I don’t care if 
> it is XSIG or XHASH which is then signed.  Mathematically they are the same.  
> This mechanism works with OPTOUT and NSEC3 as well as NSEC but does require 
> the unsigned delegations to be hashed if enabled.
>
> Mark
>
>
>
>> On Tue, Jul 10, 2018 at 10:05 AM, Wessels, Duane  
>> wrote:
>>> George,
>>>
>>>
 On Jul 9, 2018, at 4:36 PM, George Michaelson  wrote:

 There's arguments both sides about cross signing, counter signing and
 independent self-signing. If you want to promote out of band zone
 exchange, it has to be signed. The key it signs with is immaterial if
 you either direct knowledge of the PK in a PKI, or accept a trust
 anchor relationship over it, or a web of trust.
>>>
>>> I'm not here to promote out-of-band distribution, but I think its going
>>> to happen (especially for the root zone) and I want something that works
>>> just as well for in- and out-of-band distribution.
>>>
>>> I think it makes sense that name server software, whether recursive or
>>> authoritative, can use a technique like this to verify zone data, whether
>>> it is loaded from disk or received over the network.
>>>
>>> The key may be immaterial, but I think the barrier to implementation is
>>> much lower if it can be done with what we already have (DNSSEC) rather than
>>> having to drag something like PGP in.
>>>
>>>
>>>
 So do you prefer (for instance) that the ZSK be used outside of DNSSEC
 to sign a detached signature over the file, irrespective or content
 order, if the file is to be made available?
>>>
>>> Sorry I don't quite follow.  What we're suggesting is not a signature over
>>> the file/data, but a hash over the data, which in turn can be signed.
>>>
 Because if you basically
 prefer its *not signed* for this mode of transfer, you've stepped
>>>
>>> For me the mode of transfer is irrelevant.  My goal is to secure the data,
>>> not the transfer.
>>>
 outside the model: you now demand the file is checked on load, element
 by element, against the TA, rather than being integrity checked by a
 MAC signed by the issuer, which permits eg direct binary loadable, or
 other states.
>>>
>>> We're not demanding anything (MAY/SHOULD vs MUST) but what we propose is, as
>>> you say, MAC signed by the issuer.
>>>
>>> DW
>>>
>>>

 -G

 On Tue, Jul 10, 2018 at 7:47 AM, Wessels, Duane  
 wrote:
>
>> On Jul 8, 2018, at 6:02 PM, George Michaelson  wrote:
>>
>> So how about use of a PGP key which is a payload in TXT signed over by
>> the ZSK/

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Mark Andrews]

> On 10 Jul 2018, at 10:22 am, George Michaelson  wrote:
> 
> Yea, having read things properly and been hit by a cluestick I think
> this is good.
> 
> * the RR is a digest over canonicalized state
> 
> * there is a simple method to take zone, re-canonicalize (its the
> DNSSEC order) and check the digest
> 
> * since the RR is covered by the ZSK signing, the entire zone is
> understood to be in the state the publisher had when they made the
> digest.
> 
> * if you download a zone file, with this RR, you can re-canonicalize
> and check easily.
> 
> You have to have a DNSSEC ta over the keys used come what may, but
> this looks like a mechanism which given an out of band TA has no
> in-band DNS dependency to get a zone and check a zone.
> 
> So functionally, Duanes thing is identical in outcome to PGP signing
> or other exterior file signatures.
> 
> -G

The problem with what is currently there is that it requires the *entire* zone 
to walked on every dynamic update to recompute the hash.  That has always been 
the primary objection to SIG(AXFR).

We can do the hashing (and signing) on much smaller increments.

We could sign each RRset that is not already signed (GSIG) in the zone and 
introduce a glue NSEC like record (GSEC) to prevent those RRsets being removed.

We could hash larger collections of RRsets but smaller than a the whole zone.  
That is what XSIG that I proposed earlier does.  It hashes the currently 
unsigned zone data and prevents its removal from the zone.  I don’t care if it 
is XSIG or XHASH which is then signed.  Mathematically they are the same.  This 
mechanism works with OPTOUT and NSEC3 as well as NSEC but does require the 
unsigned delegations to be hashed if enabled.

Mark



> On Tue, Jul 10, 2018 at 10:05 AM, Wessels, Duane  
> wrote:
>> George,
>> 
>> 
>>> On Jul 9, 2018, at 4:36 PM, George Michaelson  wrote:
>>> 
>>> There's arguments both sides about cross signing, counter signing and
>>> independent self-signing. If you want to promote out of band zone
>>> exchange, it has to be signed. The key it signs with is immaterial if
>>> you either direct knowledge of the PK in a PKI, or accept a trust
>>> anchor relationship over it, or a web of trust.
>> 
>> I'm not here to promote out-of-band distribution, but I think its going
>> to happen (especially for the root zone) and I want something that works
>> just as well for in- and out-of-band distribution.
>> 
>> I think it makes sense that name server software, whether recursive or
>> authoritative, can use a technique like this to verify zone data, whether
>> it is loaded from disk or received over the network.
>> 
>> The key may be immaterial, but I think the barrier to implementation is
>> much lower if it can be done with what we already have (DNSSEC) rather than
>> having to drag something like PGP in.
>> 
>> 
>> 
>>> So do you prefer (for instance) that the ZSK be used outside of DNSSEC
>>> to sign a detached signature over the file, irrespective or content
>>> order, if the file is to be made available?
>> 
>> Sorry I don't quite follow.  What we're suggesting is not a signature over
>> the file/data, but a hash over the data, which in turn can be signed.
>> 
>>> Because if you basically
>>> prefer its *not signed* for this mode of transfer, you've stepped
>> 
>> For me the mode of transfer is irrelevant.  My goal is to secure the data,
>> not the transfer.
>> 
>>> outside the model: you now demand the file is checked on load, element
>>> by element, against the TA, rather than being integrity checked by a
>>> MAC signed by the issuer, which permits eg direct binary loadable, or
>>> other states.
>> 
>> We're not demanding anything (MAY/SHOULD vs MUST) but what we propose is, as
>> you say, MAC signed by the issuer.
>> 
>> DW
>> 
>> 
>>> 
>>> -G
>>> 
>>> On Tue, Jul 10, 2018 at 7:47 AM, Wessels, Duane  
>>> wrote:
 
> On Jul 8, 2018, at 6:02 PM, George Michaelson  wrote:
> 
> So how about use of a PGP key which is a payload in TXT signed over by
> the ZSK/KSK so the trust paths bind together?
> 
> fetch one DNS record +sigs, check against the TA (which has to be a
> given) and then..
 
 Currently in the zone digest draft DNSSEC is not mandatory.  That is, the 
 zone
 needn't necessarily be signed and a receiver need not perform the 
 validation if
 they don't want to.
 
 Even without DNSSEC the digest gives you a little protection from 
 accidental corruption.  But not from malicious interference of course.
 
 It seems kind of silly to me to double up on public key cryptosystems.  We 
 already have keys attached to zones and software that generates and 
 validates signatures.
 
 DW
 
>> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 

Re: [DNSOP] Genart telechat review of draft-ietf-dnsop-session-signal-11

[Joel M. Halpern]

Thank you Ted.  Those address my concerns.
Yours,
Joel

On 7/9/18 9:07 PM, Ted Lemon wrote:
I got a bit wound up about not making the three changes that Joel called 
out in the updated session signal comment, and insisted on not making 
the changes because they didn't seem that important.   I had a bit more 
private conversation with Joel about it, and after some reflection 
decided that it might be worth suggesting some changes after all based 
on Joel's comments.


What I would propose to fix these three issues are the following three 
changes.


In 5.1.3:

OLD:

Where an application-layer middlebox (e.g., a DNS proxy, forwarder,
or session multiplexer) is in the path, the middlebox MUST NOT
blindly forward DSO messages in either direction, and MUST treat the
inbound and outbound connections as separate sessions.  This does not
preclude the use of DSO messages in the presence of an IP-layer
middlebox, such as a NAT that rewrites IP-layer and/or transport-
layer headers but otherwise preserves the effect of a single session
between the client and the server.

NEW:

Where an application-layer middlebox (e.g., a DNS proxy, forwarder,
or session multiplexer) is in the path, care must be taken to avoid

inappropriately passing session signaling through the middlebox.


In cases where a DSO session is terminated on one side of a middlebox,

and then some session is opened on the other side of the middlebox in

order to satisfy requests sent over the first DSO session, any such session

MUST be treated as a separate session.


This does not

preclude the use of DSO messages in the presence of an IP-layer
middlebox, such as a NAT that rewrites IP-layer and/or transport-
layer headers but otherwise preserves the effect of a single session
between the client and the server.  And of course it does not apply

to middleboxes that do not implement DNS Stateless Operations.


These restrictions do not apply to middleboxes that do not implement

DSO: since they have no way to understand a DSO message, a pass-through

middlebox like the one described in the previous paragraph will pass

DSO messages unchanged or drop them (or possibly drop the connection).

A middlebox that is not doing a strict pass-through will have no way

to know on which connection to forward a DSO message, and therefore

will not be able to behave incorrectly.


In 5.2.2:
OLD:

A DSO response message may contain no TLVs, or it may be specified to
contain one or more TLVs appropriate to the information being
communicated.  This includes "Primary TLVs" and "Additional TLVs"
defined in this document as well as in future TLV definitions.


NEW:

A DSO response message may contain no TLVs, or it may be specified to
contain one or more TLVs appropriate to the information being
communicated.  This includes "Primary TLVs" and "Additional TLVs"
defined in this document as well as in future TLV definitions.

It may be permissible for an additional TLV to appear in a response

to a primary TLV even though the specification of that primary TLV

does not specify it explicitly.   See section 8.2 for more information.


In 5.4:
OLD:

With most TCP implementations, for DSO requests that generate a
response, the TCP data acknowledgement (generated because data has
been received by TCP), the TCP window update (generated because TCP
has delivered that data to the receiving software), and the DSO
response (generated by the receiving application-layer software
itself) are all combined into a single IP packet.  Combining these
three elements into a single IP packet can give a significant
improvement in network efficiency.


NEW:
With most TCP implementations, for DSO requests that generate a

response, the TCP data acknowledgement (generated because data has
been received by TCP), the TCP window update (generated because TCP
has delivered that data to the receiving software), and the DSO
response (generated by the receiving application-layer software
itself) are all combined into a single IP packet.  Combining these
three elements into a single IP packet can give a significant
improvement in network efficiency, assuming that the DSO response

is sent before the TCP Delayed Acknowledgement timer goes off.




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

Re: [DNSOP] Genart telechat review of draft-ietf-dnsop-session-signal-11

[Ted Lemon]

I got a bit wound up about not making the three changes that Joel called out in 
the updated session signal comment, and insisted on not making the changes 
because they didn't seem that important.   I had a bit more private 
conversation with Joel about it, and after some reflection decided that it 
might be worth suggesting some changes after all based on Joel's comments.

What I would propose to fix these three issues are the following three changes.

In 5.1.3:

OLD:
   Where an application-layer middlebox (e.g., a DNS proxy, forwarder,
   or session multiplexer) is in the path, the middlebox MUST NOT
   blindly forward DSO messages in either direction, and MUST treat the
   inbound and outbound connections as separate sessions.  This does not
   preclude the use of DSO messages in the presence of an IP-layer
   middlebox, such as a NAT that rewrites IP-layer and/or transport-
   layer headers but otherwise preserves the effect of a single session
   between the client and the server.
NEW:
   Where an application-layer middlebox (e.g., a DNS proxy, forwarder,
   or session multiplexer) is in the path, care must be taken to avoid
   inappropriately passing session signaling through the middlebox.

   In cases where a DSO session is terminated on one side of a middlebox,
   and then some session is opened on the other side of the middlebox in
   order to satisfy requests sent over the first DSO session, any such session
   MUST be treated as a separate session.

   This does not
   preclude the use of DSO messages in the presence of an IP-layer
   middlebox, such as a NAT that rewrites IP-layer and/or transport-
   layer headers but otherwise preserves the effect of a single session
   between the client and the server.  And of course it does not apply
   to middleboxes that do not implement DNS Stateless Operations.

   These restrictions do not apply to middleboxes that do not implement
   DSO: since they have no way to understand a DSO message, a pass-through
   middlebox like the one described in the previous paragraph will pass
   DSO messages unchanged or drop them (or possibly drop the connection).
   A middlebox that is not doing a strict pass-through will have no way
   to know on which connection to forward a DSO message, and therefore
   will not be able to behave incorrectly.

In 5.2.2:
OLD:
   A DSO response message may contain no TLVs, or it may be specified to
   contain one or more TLVs appropriate to the information being
   communicated.  This includes "Primary TLVs" and "Additional TLVs"
   defined in this document as well as in future TLV definitions.

NEW:
   A DSO response message may contain no TLVs, or it may be specified to
   contain one or more TLVs appropriate to the information being
   communicated.  This includes "Primary TLVs" and "Additional TLVs"
   defined in this document as well as in future TLV definitions.
   It may be permissible for an additional TLV to appear in a response
   to a primary TLV even though the specification of that primary TLV
   does not specify it explicitly.   See section 8.2 for more information.

In 5.4:
OLD:
   With most TCP implementations, for DSO requests that generate a
   response, the TCP data acknowledgement (generated because data has
   been received by TCP), the TCP window update (generated because TCP
   has delivered that data to the receiving software), and the DSO
   response (generated by the receiving application-layer software
   itself) are all combined into a single IP packet.  Combining these
   three elements into a single IP packet can give a significant
   improvement in network efficiency.

NEW:
   With most TCP implementations, for DSO requests that generate a
   response, the TCP data acknowledgement (generated because data has
   been received by TCP), the TCP window update (generated because TCP
   has delivered that data to the receiving software), and the DSO
   response (generated by the receiving application-layer software
   itself) are all combined into a single IP packet.  Combining these
   three elements into a single IP packet can give a significant
   improvement in network efficiency, assuming that the DSO response
   is sent before the TCP Delayed Acknowledgement timer goes off.

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

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[George Michaelson]

Yea, having read things properly and been hit by a cluestick I think
this is good.

* the RR is a digest over canonicalized state

* there is a simple method to take zone, re-canonicalize (its the
DNSSEC order) and check the digest

* since the RR is covered by the ZSK signing, the entire zone is
understood to be in the state the publisher had when they made the
digest.

* if you download a zone file, with this RR, you can re-canonicalize
and check easily.

You have to have a DNSSEC ta over the keys used come what may, but
this looks like a mechanism which given an out of band TA has no
in-band DNS dependency to get a zone and check a zone.

So functionally, Duanes thing is identical in outcome to PGP signing
or other exterior file signatures.

-G

On Tue, Jul 10, 2018 at 10:05 AM, Wessels, Duane  wrote:
> George,
>
>
>> On Jul 9, 2018, at 4:36 PM, George Michaelson  wrote:
>>
>> There's arguments both sides about cross signing, counter signing and
>> independent self-signing. If you want to promote out of band zone
>> exchange, it has to be signed. The key it signs with is immaterial if
>> you either direct knowledge of the PK in a PKI, or accept a trust
>> anchor relationship over it, or a web of trust.
>
> I'm not here to promote out-of-band distribution, but I think its going
> to happen (especially for the root zone) and I want something that works
> just as well for in- and out-of-band distribution.
>
> I think it makes sense that name server software, whether recursive or
> authoritative, can use a technique like this to verify zone data, whether
> it is loaded from disk or received over the network.
>
> The key may be immaterial, but I think the barrier to implementation is
> much lower if it can be done with what we already have (DNSSEC) rather than
> having to drag something like PGP in.
>
>
>
>> So do you prefer (for instance) that the ZSK be used outside of DNSSEC
>> to sign a detached signature over the file, irrespective or content
>> order, if the file is to be made available?
>
> Sorry I don't quite follow.  What we're suggesting is not a signature over
> the file/data, but a hash over the data, which in turn can be signed.
>
>> Because if you basically
>> prefer its *not signed* for this mode of transfer, you've stepped
>
> For me the mode of transfer is irrelevant.  My goal is to secure the data,
> not the transfer.
>
>> outside the model: you now demand the file is checked on load, element
>> by element, against the TA, rather than being integrity checked by a
>> MAC signed by the issuer, which permits eg direct binary loadable, or
>> other states.
>
> We're not demanding anything (MAY/SHOULD vs MUST) but what we propose is, as
> you say, MAC signed by the issuer.
>
> DW
>
>
>>
>> -G
>>
>> On Tue, Jul 10, 2018 at 7:47 AM, Wessels, Duane  
>> wrote:
>>>
 On Jul 8, 2018, at 6:02 PM, George Michaelson  wrote:

 So how about use of a PGP key which is a payload in TXT signed over by
 the ZSK/KSK so the trust paths bind together?

 fetch one DNS record +sigs, check against the TA (which has to be a
 given) and then..
>>>
>>> Currently in the zone digest draft DNSSEC is not mandatory.  That is, the 
>>> zone
>>> needn't necessarily be signed and a receiver need not perform the 
>>> validation if
>>> they don't want to.
>>>
>>> Even without DNSSEC the digest gives you a little protection from 
>>> accidental corruption.  But not from malicious interference of course.
>>>
>>> It seems kind of silly to me to double up on public key cryptosystems.  We 
>>> already have keys attached to zones and software that generates and 
>>> validates signatures.
>>>
>>> DW
>>>
>

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

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Wessels, Duane]

George,


> On Jul 9, 2018, at 4:36 PM, George Michaelson  wrote:
> 
> There's arguments both sides about cross signing, counter signing and
> independent self-signing. If you want to promote out of band zone
> exchange, it has to be signed. The key it signs with is immaterial if
> you either direct knowledge of the PK in a PKI, or accept a trust
> anchor relationship over it, or a web of trust.

I'm not here to promote out-of-band distribution, but I think its going
to happen (especially for the root zone) and I want something that works
just as well for in- and out-of-band distribution.

I think it makes sense that name server software, whether recursive or
authoritative, can use a technique like this to verify zone data, whether
it is loaded from disk or received over the network.  

The key may be immaterial, but I think the barrier to implementation is
much lower if it can be done with what we already have (DNSSEC) rather than
having to drag something like PGP in.



> So do you prefer (for instance) that the ZSK be used outside of DNSSEC
> to sign a detached signature over the file, irrespective or content
> order, if the file is to be made available?

Sorry I don't quite follow.  What we're suggesting is not a signature over
the file/data, but a hash over the data, which in turn can be signed.

> Because if you basically
> prefer its *not signed* for this mode of transfer, you've stepped

For me the mode of transfer is irrelevant.  My goal is to secure the data,
not the transfer.

> outside the model: you now demand the file is checked on load, element
> by element, against the TA, rather than being integrity checked by a
> MAC signed by the issuer, which permits eg direct binary loadable, or
> other states.

We're not demanding anything (MAY/SHOULD vs MUST) but what we propose is, as
you say, MAC signed by the issuer.

DW


> 
> -G
> 
> On Tue, Jul 10, 2018 at 7:47 AM, Wessels, Duane  wrote:
>> 
>>> On Jul 8, 2018, at 6:02 PM, George Michaelson  wrote:
>>> 
>>> So how about use of a PGP key which is a payload in TXT signed over by
>>> the ZSK/KSK so the trust paths bind together?
>>> 
>>> fetch one DNS record +sigs, check against the TA (which has to be a
>>> given) and then..
>> 
>> Currently in the zone digest draft DNSSEC is not mandatory.  That is, the 
>> zone
>> needn't necessarily be signed and a receiver need not perform the validation 
>> if
>> they don't want to.
>> 
>> Even without DNSSEC the digest gives you a little protection from accidental 
>> corruption.  But not from malicious interference of course.
>> 
>> It seems kind of silly to me to double up on public key cryptosystems.  We 
>> already have keys attached to zones and software that generates and 
>> validates signatures.
>> 
>> DW
>> 



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[George Michaelson]

There's arguments both sides about cross signing, counter signing and
independent self-signing. If you want to promote out of band zone
exchange, it has to be signed. The key it signs with is immaterial if
you either direct knowledge of the PK in a PKI, or accept a trust
anchor relationship over it, or a web of trust.

So do you prefer (for instance) that the ZSK be used outside of DNSSEC
to sign a detached signature over the file, irrespective or content
order, if the file is to be made available? Because if you basically
prefer its *not signed* for this mode of transfer, you've stepped
outside the model: you now demand the file is checked on load, element
by element, against the TA, rather than being integrity checked by a
MAC signed by the issuer, which permits eg direct binary loadable, or
other states.

-G

On Tue, Jul 10, 2018 at 7:47 AM, Wessels, Duane  wrote:
>
>> On Jul 8, 2018, at 6:02 PM, George Michaelson  wrote:
>>
>> So how about use of a PGP key which is a payload in TXT signed over by
>> the ZSK/KSK so the trust paths bind together?
>>
>> fetch one DNS record +sigs, check against the TA (which has to be a
>> given) and then..
>
> Currently in the zone digest draft DNSSEC is not mandatory.  That is, the zone
> needn't necessarily be signed and a receiver need not perform the validation 
> if
> they don't want to.
>
> Even without DNSSEC the digest gives you a little protection from accidental 
> corruption.  But not from malicious interference of course.
>
> It seems kind of silly to me to double up on public key cryptosystems.  We 
> already have keys attached to zones and software that generates and validates 
> signatures.
>
> DW
>

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

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

[Suzanne Woolf]

Thanks to all who commented. The WGLC is over and the chairs have seen strong 
support for this document and lots of participation in getting it right, so 
we’ll be advancing it for publication.

The authors will be spinning up a new version, incorporating the last call 
comments, and we’ll submit that revision.


Best,
Suzanne
(For the chairs)

> On Jun 22, 2018, at 4:01 PM, Suzanne Woolf  wrote:
> 
> Colleagues,
> 
> This begins the working group last call for 
> draft-ietf-dnsop-terminology-bis-10, "DNS Terminology”. The document has 
> gotten significant feedback and the editors have worked hard to document 
> current terminology usage, both among practitioners and for broader 
> audiences; we’d like to advance it.
> 
> We’re seeking consensus to advance it to the IESG with an intended status of 
> Best Current Practice. Note that it’s intended to obsolete RFC 7719 ( the 
> earlier “DNS Terminology” document). 
> 
> If you support it, please say so. If you don’t, please say why.
> 
> The current version is at: 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/
> 
> Last Call will run for two weeks, closing on Friday July 6. This will allow 
> for discussion of any major outstanding issues at IETF 102.
> 
> 
> thanks,
> Suzanne, Tim, & Benno

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

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Wessels, Duane]

> On Jul 8, 2018, at 8:39 PM, Olafur Gudmundsson  wrote:
> 
> So the followup question is 
> Should we burden the Auth Server implementations with this calculation if the 
> usage case if 4 zones ? 
> or is this better handled by external tools ?
> DNS Camel says ? 

IMO we should build something that works either way -- in the name server 
software or with external tools. 

DW




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Wessels, Duane]

> On Jul 8, 2018, at 6:02 PM, George Michaelson  wrote:
> 
> So how about use of a PGP key which is a payload in TXT signed over by
> the ZSK/KSK so the trust paths bind together?
> 
> fetch one DNS record +sigs, check against the TA (which has to be a
> given) and then..

Currently in the zone digest draft DNSSEC is not mandatory.  That is, the zone
needn't necessarily be signed and a receiver need not perform the validation if
they don't want to.

Even without DNSSEC the digest gives you a little protection from accidental 
corruption.  But not from malicious interference of course.

It seems kind of silly to me to double up on public key cryptosystems.  We 
already have keys attached to zones and software that generates and validates 
signatures. 

DW



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Wessels, Duane]

> On Jul 8, 2018, at 5:28 PM, Olafur Gudmundsson  wrote:
> 
> 
> +1 
> I spent lots of time earlier this century along with Johan Ihren trying to 
> figure out how to 
> secure the transfer of a particular zone (the root) to any resolver. 
> The only sane way is to not transfer the zone over AXFR as any intermediary 
> can mess with the zone contents mostly in the case of “glue” records,
> thus transferring the zone over HTTPS or RSYNC with a PGP signature over the 
> zone file is the only viable solution going forward. 

I respectfully disagree. 

I dislike PGP (and S/MIME) for a couple of reasons.  For one, I think it limits 
the use cases to non-AXFR.  You would have to either keep the original file 
in-tact (not just ordering, but character-per-character) if to be 
redistributed, or you would have to define a sorting for the data.  Any 
reformatting of the data (whitespace etc) invalidates it.  Additionally, you'd 
have to choose between detached signatures (which I think are a bad idea) or 
use a PGP attached signature format, in which case you are no longer 
distributing a file that could be directly loaded into a name server. 

Regarding HTTPS/RSYNC, that would be irrelevant.  If the data is secured then 
the transport doesn't matter at all.


>  
> 
> Historical background: SIG(AXFR) was rejected because it required putting the 
> zone into canonical order and calculating the signature, 

Thanks for that.  This little tidbit was lost in the process of editing those 
RFCs.

> in the case of dynamic update this is a real expensive operation, thus we got 
> rid of it.
> 

I agree that dynamic updates complicate zone digests.  It could be made to work 
without sorting the whole zone, but some sorting would be required.  But in 
general I don't think the complexity of digests for dynamic zones is worth it.  

DW





smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

[Dick Franks]

On 9 July 2018 at 19:48, Dave Crocker  wrote:
>8

> Does this cause anyone intolerable heart-burn?  If it does, please at
> least explain but preferably offer something better.
>

I do not suffer from intolerable heart-burn but happy to offer:

 If a public specification calls for the use of an underscore-prefixed
domain name,
the underscored name closest to the root MUST be entered into this registry.

(Editorial:  The word underscore does not itself need to be
underscore_prefixed)

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

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

[Dave Crocker]

On 7/9/2018 2:09 PM, John Levine wrote:

Since it'll always be on the right for people reading this document in English,
I'd rather leave it alone.



Except that a) RFCs get translated, and b) people implement RFCs all 
over the world, including places that display rtl.  (cf, 'robustness'.)


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

[John Levine]

In article <9ab5e7e3-2959-2e3c-135d-d749e0aa6...@dcrocker.net> you write:
>to:
>  If a public specification calls for use of an
> _underscore-prefixed domain node name, the 'global'
> (highest level, and typically right-most) _underscored name MUST
> be entered into this registry. 

I only have minor dyspepsia because someone will surely take this as
as an indication that somewhere in the anglophone world, domains are
displayed with the root on the left.  Or maybe at the top.  No doubt
the founders of JANET would be amused.

Since it'll always be on the right for people reading this document in English,
I'd rather leave it alone.

R's,
John

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

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

[Dave Crocker]

On 7/6/2018 8:22 AM, Stephane Bortzmeyer wrote:

On Mon, Jun 25, 2018 at 12:27:17PM +0200,
  Benno Overeinder  wrote
  a message of 27 lines which said:


This starts a Working Group Last Call for draft-ietf-dnsop-attrleaf


I've read -10 and it seems OK. It solves a real issue, and does it
properly.

Editorial: I would prefer all occurrences of "right-most" to be
replaced by "most general", to emphasize that it is not the position
which matters, it is the closeness to the root.



G'day.

Given the reality of arguably-legitimate left-to-right domain name 
hierarchy presentation in some contexts, and given a desire to have 
specification text that is both correct and robust, I'm going to suggest 
a bit more verbosity in the attrleaf document, along the lines of...



from:

 If a public specification calls for use of an
_underscore-prefixed domain node name, the 'global'
(right-most) _underscored name MUST be entered into this
 registry. 

to:
 If a public specification calls for use of an
_underscore-prefixed domain node name, the 'global'
(highest level, and typically right-most) _underscored name MUST
be entered into this registry. 


Does this cause anyone intolerable heart-burn?  If it does, please at 
least explain but preferably offer something better.


Thanks.


d/

--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa

[JORDI PALET MARTINEZ]

I'm with you, ideally they should use DHCPv6 ... so tell them :-)



Regards,

Jordi

 

 



-Mensaje original-

De:  en nombre de Philip Homburg 


Fecha: lunes, 9 de julio de 2018, 18:26

Para: 

CC: JORDI PALET MARTINEZ 

Asunto: Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa 



> I think deprecating

> RFC7050 will be a bad idea, there are too many implementations that

> really need that, while updating APIs/libraries to make sure they

> comply with this seems easier.

> 

> For example, we could have a DHCPv6 option, but in the cellular

> world DHCPv6 is not used ... and even in non-cellular, Android is

> not using it either.



You are saying that countless stub resolvers should special case

ipv4only.arpa just because some operators don't want to deploy DHCPv6?



In many cases, there is not even a sensible mechanism to make this work.

A stub resolver often reads /etc/resolv.conf. If that contains just a

public resolver, then there is not much that can be done.






**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.



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

Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa

[Philip Homburg]

> I think deprecating
> RFC7050 will be a bad idea, there are too many implementations that
> really need that, while updating APIs/libraries to make sure they
> comply with this seems easier.
> 
> For example, we could have a DHCPv6 option, but in the cellular
> world DHCPv6 is not used ... and even in non-cellular, Android is
> not using it either.

You are saying that countless stub resolvers should special case
ipv4only.arpa just because some operators don't want to deploy DHCPv6?

In many cases, there is not even a sensible mechanism to make this work.
A stub resolver often reads /etc/resolv.conf. If that contains just a
public resolver, then there is not much that can be done.

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

Re: [DNSOP] Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

[Michael StJohns]

Tim/Suzanne -

Please cancel the request for publication until you complete the WGLC 
for this document.


The last WGLC for the document was October of last year - it failed on 
28 October 
https://www.ietf.org/mail-archive/web/dnsop/current/msg21225.html. No 
WGLC has been made since then.


The consensus referenced in the shepherd's report was meeting consensus 
- not mailing list consensus AFAICT.  Specifically, I'd like to see if 
Ed's removed his objections.  I don't have a problem with the WGLC being 
used to judge consensus - but that's not what happened here.


Later, Mike


On 7/6/2018 9:08 PM, Michael StJohns wrote:

On 7/6/2018 8:13 PM, Tim Wicinski wrote:
Tim Wicinski has requested publication of 
draft-ietf-dnsop-rfc5011-security-considerations-12 as Proposed 
Standard on behalf of the DNSOP working group.


Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/


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


*sigh*

Point of order:  Did I miss the final WGLC on this after this last 
version was published?  I can't actually find anything in the DNSOP 
archives and I don't remember seeing the call.   So I'm suggesting 
that we've missed a required stage.


With respect to the shepher's writeup:

1) The first reference in the shepherd's write-up  is wrong - its 
pointing to a whole other set of discussions related to Joe Abley's 
ideas.
2) The second reference isn't representative of the actual discussion, 
but only shows the point at which I got worn down. Please include a 
reference that actually shows the attempts to try and resolve my issues.
3) This document should not be a Proposed Standard as it documents 
nothing implementable (that is nothing implementable in a computer), 
but is operational guidance for the publication process.
4) Is it usual for the WG chair to write the shepherd's report? 
Specifically, it seems a conflict of interest for items (3) -(6).
5) The technical summary is misleading.  This is not an update to 
5011, but guidance to the zone publisher who may have not understood 
the implications of operational choices (e.g. steady state single 
trust anchor vs 5011s recommendation of multiple trust anchors). E.g. 
"RFC5011 DNSSEC Key Rollover Strategy" isn't a document referenced by 
this document, and that would be the document that would be in need of 
an update.
6) Same comment - it's not an update to the 5011 timers, but to the 
understanding of the publishers of such zones that use 5011.
7) Please include references of the emails of the "root server 
community" review - AFAICT, Ed Lewis was the only one to comment on 
the list and the last comment was last year.


Mike


Mike








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

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

[Benno Overeinder]

Hi all,

Procedure/process update.

As announced, the WG LC should/would be closed today, but draft
reviewers suggested to run attrleaf and attrleaf-fix together through
the process.  The WG LC will be closed this Wednesday, July 11th for
both attrleaf and attrleaf-fix.

-- Benno


On 07/07/2018 08:55, Tim Wicinski wrote:
> (no hats)
> 
> I've read the -10 version and I'm very happy how Dave has split the
> documents up.  
> 
> I have not finished going through the attrleaf-fix. 
> 
> I do like Ondrej's comment about bundling the two documents.  They do
> work well together.
> 
> thanks Dave. 
> Tim
> 
> 
> On Fri, Jul 6, 2018 at 1:26 PM, John R Levine  > wrote:
> 
> On Fri, 6 Jul 2018, Dave Crocker wrote:
> 
>  Translator's note: change this to "left most" when translated
>  to Arabic or Hebrew.
> 
> 
> in rtl contexts, domain names are shown with the root at the left???
> 
> 
> If they're IDNs in rtl languages, apparently so.  If they're a mix,
> or all ltr, it's anyone's guess.  When writing up advice on
> implementing EAI addresses I talked to people who use the Internet
> in Arabic and the message I got was that it's rather confused.
> 
> Regards,
> John Levine, jo...@taugh.com , Taughannock
> Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
> https://jl.ly
> 
> ___
> 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 mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

[Lanlan Pan]

Anthony Eden 于2018年6月20日周三 上午12:06写道：

> On Tue, Jun 19, 2018 at 4:47 PM, Lanlan Pan  wrote:
>
>>
>>
>> Petr Špaček 于2018年6月19日周二 下午9:19写道：
>>
>>> Hello dnsop,
>>>
>>> beware, material in this e-mail might cause your head to explode :-)
>>>
>>> This proposal is based on following observations:
>>> - It seems that DNS protocol police lost battle about CNAME at apex,
>>>is is deployed on the Internet.
>>> - Major DNS resolvers like BIND, Unbound, PowerDNS Recursor, dnsmasq
>>>already have code to cope with the "impossible" case of CNAME at the
>>>apex and deal with it in ways which do not break stuff on resolver
>>>side.
>>> - Authoritative servers of vendors named above refuse to serve CNAME at
>>>apex.
>>> - There are CDNs etc. which allow users to create CNAME at apex
>>>no matter what the standards and "normal" servers say and do.
>>> (We have found out this because Knot Resolver is missing hacks for CNAME
>>> at apex and users complain that "it works with every other resolver".)
>>>
>>>
>>> Take a deep breath!
>>>
>>>
>>> Given that resolver side somehow works already ...
>>> could we standardize this obvious violation of RFC 1035?
>>>
>>> It is very clear violation of the standard, but almost everyone found
>>> his way around it using different hacks. These hacks are not going away
>>> because all the CDNs just don't care about standards so we will have
>>> to maintain this code no matter what a great solution we will invent for
>>> future. I.e. adding ANAME will just increase complexity because CNAME at
>>> apex will be there for a long time (if not forever).
>>>
>>> I personally do not like this but it seems better to think though
>>> corner cases in code we already have in production (i.e. think through
>>> current hacks for CNAME at apex) instead of inventing new things like
>>> ANAME (or whatever else).
>>>
>> I think ANAME RR is hard to compatible with many old version resolvers.
>> If there are mutiple ANAME RR at compatible resolvers, authoritatives may
>> not know that resolvers will choose which A RR for client response.
>>
>> ANAME can ease apex CNAME configuration, maybe a work round is that
>> authoritatives directly return A RR to resolvers (but not ANAME RR).
>>
>
> This is essentially what those of us who implemented ANAME in
> authoritative name servers do right now. The original draft I started about
> ALIAS records also spelled out only this solution with some operational
> guidance on best practices.
>

Section 4. Recursive Server Behavior:  send client subnet  when query ANAME
target ?
Would it be simpler director send client subnet when first query ?

Anyway, one of ANAME's benefits is that it can return both  and A in
one response.


>
>>
>>> Opinions? Tomatoes? Can it work? If not, why not?
>>>
>>> --
>>> Petr Špacek  @  CZ.NIC
>>>
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>> --
>> 致礼  Best Regards
>>
>> 潘蓝兰  Pan Lanlan
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>
>
> --
> DNSimple.com
> http://dnsimple.com/
> Twitter: @dnsimple
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop