[DNSOP] 答复: Call for Adoption: draft-bortzmeyer-rfc7816bis

[宋林健]

+1

 

DNS privacy is an important issue. I support this adoption. And I’m willing to 
review it. 

 

Davey

发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Tim Wicinski
发送时间: 2018年7月25日 0:33
收件人: dnsop
主题: [DNSOP] Call for Adoption: draft-bortzmeyer-rfc7816bis

 

 

We discussed this and there appears to be support to adopt this, with

the caveat of adding more content to the section on Operational Considerations.

 

 

This starts a Call for Adoption for draft-bortzmeyer-rfc7816bis

 

The draft is available here: 
https://datatracker.ietf.org/doc/draft-bortzmeyer-rfc7816bis/

 

Please review this draft to see if you think it is suitable for adoption

by DNSOP, and comments to the list, clearly stating your view.

 

Please also indicate if you are willing to contribute text, review, etc.

 

This call for adoption ends: 9 August 2018

 

Thanks,

tim wicinski

DNSOP co-chair

 

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

Re: [DNSOP] Call for Adoption: draft-kh-dnsop-7706bis

[Paul Hoffman]

On 24 Jul 2018, at 10:35, Paul Wouters wrote:

While I agree with the goal of the draft, to keep root server queries 
on
the local host, I don't like how it is suggesting to run a DNS server 
on

localhost:53, because that is going to cause problems with running
validating resolvers on the stub. There is already enough racy
conditions on systems with virtual machines and running dhcp/dns 
servers

for those that are racing to own 127.0.0.1:53


If you find a place where the draft is suggesting that, please let us 
know: it should not be doing that. That's why the draft explicitly 
states:


.. . .
   2.  Start the authoritative server with the root zone on an address
   on the host that is not in use.  For IPv4, this could be
   127.0.0.1, but if that address is in use, any address in 127/8 
is

   acceptable.  For IPv6, this would be ::1.
.. . .
   The examples here use a loopback address of 127.12.12.12, but 
typical

   installations will use 127.0.0.1.  The different address is used in
   order to emphasize that the root server does not need to be on the
   device at the name "localhost" which is often locally served as
   127.0.0.1.
.. . .

But again, having a well integrated method for slaving the root zone 
on

a local validating stub resolver is something that everyone should do
(along with query minimalization)


Hopefully, that's a recommendation for adoption of the draft.

--Paul Hoffman

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

Re: [DNSOP] Call for Adoption: draft-kh-dnsop-7706bis

[John Levine]

In article  you write:
>the local host, I don't like how it is suggesting to run a DNS server on
>localhost:53

That seems easy enough to fix, move it to another address in 127/8 or
a different port.  I agree that there's a lot of software that expects
to find a local DNS cache on localhost:53 so it's not a good place to
put something else.

R's,
John

PS: I agree with the call for adoption.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

[Dave Crocker]

On 7/23/2018 2:22 PM, Tim Wicinski wrote:

ooks like a typo.  That has been there for a bit.


...

  The table on page 6 includes:

"._protoB._service2"



Given that it's the only one like that, yes, it should be changed.

Just to bikeshed the issue, note that it's not 'wrong' to have the dot 
there, given the nature of this registration activity and therefore the 
context that the examples are going to get used in.


But certainly things need to be consistent and that one isn't.

Thanks for catching it, Bob.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [DNSOP] howto "internal"

[Grant Taylor]

Paul,

On 07/24/2018 10:10 AM, Paul Vixie wrote:
i also use real domains for my private stuff. but i also use RPZ locally 
for the internal bindings,


Do you leverage anything like Dynamic DNS updates in conjunction with 
DHCP?  If so, how well does that play with the configuration that you're 
using?


not NS RR delegations that i'd have to keep out of my externally-served 
zone files.


Is there a best practice around this method of delegating to 
sub-domain(s) that are inaccessible to the public?


Is it better to return NODATA or NXDOMAIN to global clients querying for 
host.sub-domain.example.net?  Or is there a different error that can be 
returned to indicate no access?


I guess there's always delegating to a server that is inaccessible 
externally too.




--
Grant. . . .
unix || die



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

Re: [DNSOP] Call for Adoption: draft-kh-dnsop-7706bis

[Ted Lemon]

Can you unpack that a bit, Paul?   What's the scenario where this is a
problem?   Not disagreeing, just not seeing it.

On Tue, Jul 24, 2018 at 1:35 PM, Paul Wouters  wrote:

> On Tue, 24 Jul 2018, Tim Wicinski wrote:
>
> We discussed this and there appears to be support to adopt this, with
>> the caveat of fleshing out some of the discussions which came up.
>>
>>
>> This starts a Call for Adoption for draft-kh-dnsop-7706bis
>>
>> The draft is available here: https://datatracker.ietf.org/d
>> oc/draft-kh-dnsop-7706bis/
>>
>
> While I agree with the goal of the draft, to keep root server queries on
> the local host, I don't like how it is suggesting to run a DNS server on
> localhost:53, because that is going to cause problems with running
> validating resolvers on the stub. There is already enough racy
> conditions on systems with virtual machines and running dhcp/dns servers
> for those that are racing to own 127.0.0.1:53
>
> But again, having a well integrated method for slaving the root zone on
> a local validating stub resolver is something that everyone should do
> (along with query minimalization)
>
> Paul
>
> ___
> 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] howto "internal"

[Grant Taylor]

On 07/24/2018 09:08 AM, Petr Špaček wrote:

I would recommend you to use subdomain of your public domain.


Agreed.

The alternative might be to use a different public domain.


Nice thing is that this approach doesn't require:
- views
- forwarding
- explicit trust anchor (if you want DNSSEC inside internal network)


Public (sub)domain(s) also make it easier to use external / 3rd party 
CAs.  -  Rather I've found it difficult to use private / non-public 
(sub)domain(s) when using public CAs.




--
Grant. . . .
unix || die



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

Re: [DNSOP] Call for Adoption: draft-bortzmeyer-rfc7816bis

[Paul Wouters]

On Tue, 24 Jul 2018, Tim Wicinski wrote:


We discussed this and there appears to be support to adopt this, with
the caveat of adding more content to the section on Operational Considerations.


This starts a Call for Adoption for draft-bortzmeyer-rfc7816bis

The draft is available here: 
https://datatracker.ietf.org/doc/draft-bortzmeyer-rfc7816bis/


I strongly support this effort and would like this work to be adopted by
the WG and will commit to contribute text and reviews.

I would like it if it would update some older core DNS RFCs to ensure
that this method of resolving becomes the preferred and default method
for recursive querying (that is, make this method a SHOULD or MUST)

Paul

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

Re: [DNSOP] Call for Adoption: draft-kh-dnsop-7706bis

[Paul Wouters]

On Tue, 24 Jul 2018, Tim Wicinski wrote:


We discussed this and there appears to be support to adopt this, with
the caveat of fleshing out some of the discussions which came up.


This starts a Call for Adoption for draft-kh-dnsop-7706bis

The draft is available here: 
https://datatracker.ietf.org/doc/draft-kh-dnsop-7706bis/


While I agree with the goal of the draft, to keep root server queries on
the local host, I don't like how it is suggesting to run a DNS server on
localhost:53, because that is going to cause problems with running
validating resolvers on the stub. There is already enough racy
conditions on systems with virtual machines and running dhcp/dns servers
for those that are racing to own 127.0.0.1:53

But again, having a well integrated method for slaving the root zone on
a local validating stub resolver is something that everyone should do
(along with query minimalization)

Paul

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

[DNSOP] Call for Adoption: draft-kh-dnsop-7706bis

[Tim Wicinski]

We discussed this and there appears to be support to adopt this, with
the caveat of fleshing out some of the discussions which came up.


This starts a Call for Adoption for draft-kh-dnsop-7706bis

The draft is available here:
https://datatracker.ietf.org/doc/draft-kh-dnsop-7706bis/

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 9 August 2018

Thanks,
tim wicinski
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Call for Adoption: draft-bortzmeyer-rfc7816bis

[Tim Wicinski]

We discussed this and there appears to be support to adopt this, with
the caveat of adding more content to the section on Operational
Considerations.


This starts a Call for Adoption for draft-bortzmeyer-rfc7816bis

The draft is available here:
https://datatracker.ietf.org/doc/draft-bortzmeyer-rfc7816bis/

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 9 August 2018

Thanks,
tim wicinski
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] missing entries from draft-ietf-dnsop-attrleaf-12.txt

[Tony Finch]

John Levine  wrote:
>
> The _tls is in an example, and it's probably wrong, but it's there so
> I figure we should list it.

_tls in the protocol field is used by non-standard proprietary
technologies including Microsoft Lync / Skype for Business and Cisco
Jabber / Collaboration Edge. Maybe others?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
harness technological change to human advantage

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

Re: [DNSOP] howto "internal"

[Tim Wicinski]

On Tue, Jul 24, 2018 at 12:10 PM, Paul Vixie  wrote:

>
>
>>
> i also use real domains for my private stuff. but i also use RPZ locally
> for the internal bindings, not NS RR delegations that i'd have to keep out
> of my externally-served zone files



I had forgotten our threat intelligence teams use RPZ internally as well,
absolutely.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] howto "internal"

[Paul Vixie]

Tim Wicinski wrote:

At my employer we use real domains, but do not expose them to the
outside world (they just see 127.0.0.1).   It's a better than inverting
  security through obscurity like I have seen elsewhere (not that you
would do that Andreas).

Paul,  I am not with 100% love of the .alt name./idea but I do agree
that if we don't do something the Real Users (tm) will do something even
more broken and horrific.


i also use real domains for my private stuff. but i also use RPZ locally 
for the internal bindings, not NS RR delegations that i'd have to keep 
out of my externally-served zone files.


--
P Vixie

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

Re: [DNSOP] howto "internal"

[Joe Abley]

Hi Andreas,

One problem with using non-unique namesapaces is that if you ever find yourself 
needing to join your infrastructure to someone else's you run the risk of 
collisions. 

[This is an analogue to the problem at the IP layer with using RFC 1918 
addresses -- if I'm already using 192.168.1.0/24 and so is the other person, 
either one of us needs to renumber or we need a world of translation complexity 
to be able to talk to each other.]

My usual answer to your question is to register a domain for internal use and 
name everything within it. You can make the DNS records available to your 
internal resolver and not even delegate the zone in the public DNS if you like. 
The point of the registration is just uniqueness.

Using a subdomain of a name you already use is a functionally-equivalent 
answer, but it involves some degree of change to domain names you already use. 
Even if this is clearly low-cost today, it might add unwelcome complexity in 
the future.

There are many more angles to the wider discussion about new TLDs like 
internal, alt, etc or using names under example.com, but in your case since you 
get to start from scratch I think a few dollars per year to reserve a unique 
name is a cheap and good answer.


Joe

> On Jul 24, 2018, at 10:52, A. Schulze  wrote:
> 
> Hello,
> 
> some times ago there was an proposal (?) from Warren Kumari to define a zone 
> "internal." for internal use.
> 
> We consider a major DNS redesign of a large enterprise network. Part of the 
> network is private (RFC1918 address space in use)
> some other parts are public. The whole network is currently organized as 
> subdomains of example.com. 
> 
> One problem is the inability of users to distinguish the public/private state 
> of different subdomains.
> sub1.example.com is public, sub2.example.com isn't :-/
> 
> For that I like the proposal to use "internal." But that's far away from 
> being a standard.
> So I like to ask about alternatives...
> 
> Thanks for suggestions
> Andreas
> 
> ___
> 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] missing entries from draft-ietf-dnsop-attrleaf-12.txt

[John Levine]

I did some greppage through the RFCs and found some more names to go
in the attrleaf table.

   ++-++
   | RR Type| _NODE NAME  | REFERENCE  |
   ++-++
   | TLSA   | _dane   | [RFC7671]  |
   | SRV| _ipv6   | [RFC5026]  |
   | SRV| _sip| [RFC5509]  |
   | SRV| _xmpp   | [RFC3921]  |
   | SRV| _tls| [RFC6733]  |
   ++-++

For _sip and _xmpp, also see the Instant Messaging SRV Protocol Label
Registry and the Presence SRV Protocol Label Registry.

The _tls is in an example, and it's probably wrong, but it's there so
I figure we should list it.

R's,
John

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

Re: [DNSOP] howto "internal"

[Tim Wicinski]

At my employer we use real domains, but do not expose them to the outside
world (they just see 127.0.0.1).   It's a better than inverting  security
through obscurity like I have seen elsewhere (not that you would do
that Andreas).

Paul,  I am not with 100% love of the .alt name./idea but I do agree that
if we don't do something the Real Users (tm) will do something even more
broken and horrific.

Tim

On Tue, Jul 24, 2018 at 11:32 AM, Tony Finch  wrote:

> Petr Špaček  wrote:
> >
> > My operational experience indicates that it is easiest to just use
> > "corp.example.com.", "office.example.com.", or even "i.example.com.".
>
> We use private.cam.ac.uk.
>
> > Nice thing is that this approach doesn't require:
> > - views
>
> We have an empty version of private.cam.ac.uk in an external view,
> originally set up to avoid problems with CAA checking for X.509
> certificates. It also massively reduces retries for REFUSED queries from
> outside. (Our qps went down by about 50% when we introduced this view!)
>
> > - forwarding
>
> However you do still need forwarding (or stealth secondarying) for RFC1918
> reverse DNS. Catalog zones make stealth secondaries almost as easy as
> forwarding to set up and maintain :-)
>
> > - explicit trust anchor (if you want DNSSEC inside internal network)
> >
> > and generally just works :-)
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Sole: Westerly backing southerly, 3 or 4, increasing 5 or 6 later in west..
> Slight, becoming moderate in west. Mainly fair. Moderate or good.
> ___
> 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] howto "internal"

[Tony Finch]

Petr Špaček  wrote:
>
> My operational experience indicates that it is easiest to just use
> "corp.example.com.", "office.example.com.", or even "i.example.com.".

We use private.cam.ac.uk.

> Nice thing is that this approach doesn't require:
> - views

We have an empty version of private.cam.ac.uk in an external view,
originally set up to avoid problems with CAA checking for X.509
certificates. It also massively reduces retries for REFUSED queries from
outside. (Our qps went down by about 50% when we introduced this view!)

> - forwarding

However you do still need forwarding (or stealth secondarying) for RFC1918
reverse DNS. Catalog zones make stealth secondaries almost as easy as
forwarding to set up and maintain :-)

> - explicit trust anchor (if you want DNSSEC inside internal network)
>
> and generally just works :-)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Sole: Westerly backing southerly, 3 or 4, increasing 5 or 6 later in west.
Slight, becoming moderate in west. Mainly fair. Moderate or good.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] howto "internal"

[Paul Vixie]

i do not love the 
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-10 draft, 
but i would love even less to see it reinvented in our ignorance.


re:

Ted Lemon wrote:

It would probably be easier to get internal.arpa, similar to home.arpa.
  You could use home.arpa now, but it would look a little funny... :)

On Tue, Jul 24, 2018 at 10:52 AM, A. Schulze mailto:s...@andreasschulze.de>> wrote:

Hello,

some times ago there was an proposal (?) from Warren Kumari to
define a zone "internal." for internal use.

We consider a major DNS redesign of a large enterprise network. Part
of the network is private (RFC1918 address space in use)
some other parts are public. The whole network is currently
organized as subdomains of example.com .

One problem is the inability of users to distinguish the
public/private state of different subdomains.
sub1.example.com  is public,
sub2.example.com  isn't :-/

For that I like the proposal to use "internal." But that's far away
from being a standard.
So I like to ask about alternatives...

Thanks for suggestions
Andreas

___
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


--
P Vixie

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

Re: [DNSOP] howto "internal"

[Ted Lemon]

It would probably be easier to get internal.arpa, similar to home.arpa.
 You could use home.arpa now, but it would look a little funny... :)

On Tue, Jul 24, 2018 at 10:52 AM, A. Schulze  wrote:

> Hello,
>
> some times ago there was an proposal (?) from Warren Kumari to define a
> zone "internal." for internal use.
>
> We consider a major DNS redesign of a large enterprise network. Part of
> the network is private (RFC1918 address space in use)
> some other parts are public. The whole network is currently organized as
> subdomains of example.com.
>
> One problem is the inability of users to distinguish the public/private
> state of different subdomains.
> sub1.example.com is public, sub2.example.com isn't :-/
>
> For that I like the proposal to use "internal." But that's far away from
> being a standard.
> So I like to ask about alternatives...
>
> Thanks for suggestions
> Andreas
>
> ___
> 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] howto "internal"

[Petr Špaček]

Hello,

On 24.7.2018 16:52, A. Schulze wrote:
> some times ago there was an proposal (?) from Warren Kumari to define a zone 
> "internal." for internal use.
> 
> We consider a major DNS redesign of a large enterprise network. Part of the 
> network is private (RFC1918 address space in use)
> some other parts are public. The whole network is currently organized as 
> subdomains of example.com. 
> 
> One problem is the inability of users to distinguish the public/private state 
> of different subdomains.
> sub1.example.com is public, sub2.example.com isn't :-/
> 
> For that I like the proposal to use "internal." But that's far away from 
> being a standard.
> So I like to ask about alternatives...

I would recommend you to use subdomain of your public domain.

My operational experience indicates that it is easiest to just use
"corp.example.com.", "office.example.com.", or even "i.example.com.".

These are legible to users and clearly indicate that anything below it
is internal name only. The rest of matter of configuration on the
authoritative server.

Nice thing is that this approach doesn't require:
- views
- forwarding
- explicit trust anchor (if you want DNSSEC inside internal network)

and generally just works :-)

-- 
Petr Špaček  @  CZ.NIC

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

[John Levine]

In article <9da145f4-df6a-4bfa-b3c9-56027b228...@iis.se> you write:
>-=-=-=-=-=-
>In table 2 on page 9, the draft refers to RFC 2782 for _dccp and _sctp (SRV), 
>but those “_node names”
>are not even mentioned in the RFC. Are they defined elsewhere?

RFC 2782 says that SRV's are named with _proto where proto is is a
protocol name.  RFCs 3588 and 6733 say to do _sctp SRV lookups, but
don't further define them, and only have 2782 as an informative
reference.  No RFC mentions _dccp.  

It seems to me that 2782 is the right reference for _sctp.  For _dccp
we've had arguments about whether 2782 says that a SRV can be named by
any protocol so maybe we should put in every protocol in the IANA
registry.  That's a lot of dead protocols.  A reasonable compromise
would be to start the registry with the names that have some evidence
of being used somewhere, so we could drop _dccp

>In the same table, the draft refers to RFC 7553 for a number of URI _node 
>names, but the references are quite
>indirect. Could references to relevant IANA registries be added?

Since RFC 7553 is the place that says that the enumservice names turn
into _node names, I think that's the right reference.

R's,
John


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

[DNSOP] howto "internal"

[A. Schulze]

Hello,

some times ago there was an proposal (?) from Warren Kumari to define a zone 
"internal." for internal use.

We consider a major DNS redesign of a large enterprise network. Part of the 
network is private (RFC1918 address space in use)
some other parts are public. The whole network is currently organized as 
subdomains of example.com. 

One problem is the inability of users to distinguish the public/private state 
of different subdomains.
sub1.example.com is public, sub2.example.com isn't :-/

For that I like the proposal to use "internal." But that's far away from being 
a standard.
So I like to ask about alternatives...

Thanks for suggestions
Andreas

___
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

[John Levine]

In article <87h8kp7sqf@mid.deneb.enyo.de> you write:
>The ZONEMD record should contain a size indicator for the zone,
>something that allows a receiver to stop downloading if it is clear
>that the served zone is too large.  Otherwise, the receiver has to
>download the entire zone before it can determine that the hash does
>not match.

I don't understand why this is a problem that needs solving.  Are we
really attacked by broken zone files with large amounts of added junk,
that are so large that reading them through before discarding them is
a practical performance problem?

I'd think that more likely problems would be that a file was
truncated, or that it was the right size but some entries are
corrupted.

R's,
John





___
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

[Paul Vixie]

larger zones cannot afford to recalculate a non-incremental zone hash on 
every single update. is there hope that the zonemd proposal becomes 
incremental before release?


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt

[Mats Dufberg]

In table 2 on page 9, the draft refers to RFC 2782 for _dccp and _sctp (SRV), 
but those “_node names” are not even mentioned in the RFC. Are they defined 
elsewhere?

In the same table, the draft refers to RFC 7553 for a number URI _node names, 
but the references are quite indirect. Could references to relevant IANA 
registries be added?


Mats

---
Mats Dufberg
DNS Specialist, IIS
Mobile: +46 73 065 3899
https://www.iis.se/en/


From: DNSOP  on behalf of Bob Harold 

Date: Monday, 23 July 2018 at 22:22
To: IETF DNSOP WG 
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt


On Sat, Jul 21, 2018 at 12:11 PM 
mailto:internet-dra...@ietf.org>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : DNS Scoped Data Through "Underscore" Naming of 
Attribute Leaves
Author  : Dave Crocker
Filename: draft-ietf-dnsop-attrleaf-12.txt
Pages   : 13
Date: 2018-07-21

Abstract:
   Formally, any DNS resource record may occur under any domain name.
   However some services have defined an operational convention, which
   applies to DNS leaf nodes that are under a DNS branch having one or
   more reserved node names, each beginning with an _underscore.  The
   underscored naming construct defines a semantic scope for DNS record
   types that are associated with the parent domain, above the
   underscored branch.  This specification explores the nature of this
   DNS usage and defines the "DNS Global Underscore Scoped Entry
   Registry" with IANA.  The purpose of the Underscore registry is to
   avoid collisions resulting from the use of the same underscore-based
   name, for different services.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-12
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-12


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

[DNSOP] [lau...@miscnote.net: difference between dns spoofing and dns hijacking?]

[Stephane Bortzmeyer]

Some work for draft-ietf-dnsop-terminology-ter? Define spoofing,
poisoning and hijacking?

--- Begin Message ---

I saw the info from google,

While the DNS hijacking involves a malware, the DNS Cache poisoning 
involves overwriting your local DNS cache with fake values that redirect 
your browser to malicious websites. ... Though DNS Cache Poisoning and 
DNS Hijacking are used interchangeably, there is a small difference 
between them.


Not very sure about the explanation.
Can you kindly expand it?

thanks.
___
dns-operations mailing list
dns-operati...@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-operations mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
--- End Message ---
___
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

[Florian Weimer]

* Duane Wessels:

> I wouldn't be opposed to this in principle -- say an RR count field.  

That doesn't really bound the amount of transferred data, I think,
because RR size can still vary widely.  I believe something that
counts the hashed bytes would be more helpful and about as easy to
implement.

> For this to be useful in an unsigned zone then all you need is for the
> ZONEMD (with RR count field) to be received early in the AXFR.  If it
> is at the end then this field doesn't help.
>
> For a signed zone, we'd have to think about whether the ZONEMD record
> should be DNSSEC validated before trusting the RR count field.  If yes
> then you need the signatures and NSEC* records too, so it becomes sort
> of complex when you'd be able to trust and check the RR count.

Could you query it before the transfer.

> But it seems to me like this is better suited to be a feature of AXFR
> in general, rather than ZONEMD.

It depends on what you want to achieve with ZONEMD.  If you want to
prevent trivial, but potentially persistent DoS attacks with custom
root servers, you need it in ZONEMD.

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