+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
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.
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
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
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
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
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
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:
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:
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
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:
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
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
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
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
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
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
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
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
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
* 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
21 matches
Mail list logo
