On 06/20/2018 04:59 PM, Tom Pusateri wrote:
> DNSSEC will tell you the answer you get is correct but it could be a > to a
> different question or be incomplete.
Can you elaborate on that point. I believe in signed zones you are able
to verify almost everything, in particular existence of the
On Tue, Jun 19, 2018 at 7:15 PM Mukund Sivaraman wrote:
>
> There also seems to be a scalability problem with SIG(0) in that
> generating the signature involves a public-key operation per DNS
> message.
>
> For a zone transfer of the root zone from F, the AXFR contains 79
> messages in the TCP
On Wed, Jun 20, 2018 at 7:30 PM Joe Abley wrote:
> On Jun 20, 2018, at 19:07, Warren Kumari wrote:
>
> ... what I'd alway wanted[0] was to be able to setup my own recursive
> name server somewhere on the Internet, and then only allow myself (and a
> few of my closest friends) to be able to
> On 21 Jun 2018, at 2:37 am, Mukund Sivaraman wrote:
>
> On Wed, Jun 20, 2018 at 09:48:40AM +1000, Mark Andrews wrote:
>> Donald Eastlake’s early DNSSEC work had a working zone signature. It doesn’t
>> require signing each message. It’s just relatively expensive to compute for
>> large zones
On Jun 20, 2018, at 19:07, Warren Kumari wrote:
... what I'd alway wanted[0] was to be able to setup my own recursive name
server somewhere on the Internet, and then only allow myself (and a few of
my closest friends) to be able to query it.
For this particular use-case, why is SIG(0) better
Warren Kumari wrote:
...
... what I'd alway wanted[0] was to be able to setup my own recursive
name server somewhere on the Internet, and then only allow myself (and a
few of my closest friends) to be able to query it.
1: Obviously having it as an open-recursive is not the answer (e.g it
On Tue, Jun 19, 2018 at 5:04 PM Tony Finch wrote:
> Ondřej Surý wrote:
> >
> > Do people think the SIG(0) is something that we should keep in DNS and
> > it will be used in the future or it is a good candidate for throwing off
> > the boat?
>
> SIG(0) is the only DNS feature that (could) allow
In article <38b08915-4649-454c-addf-b21422386...@isc.org> you write:
>Oh, what about this?
>
>https://tools.ietf.org/html/draft-sury-dnsext-cname-dname-00
>
>:-)
I think it would work in the DNS but it wouldn't solve any real
problems.
If you want to make your applications work with parallel or
> On 21 Jun 2018, at 12:25 am, Petr Špaček wrote:
>
> On 20.6.2018 16:10, Paul Wouters wrote:
>> On Wed, 20 Jun 2018, Petr Špaček wrote:
>>
>>> it seems that current specification of DNS cookies in RFC 7873 is not
>>> detailed enough to allow deployment of DNS cookies in multi-vendor
>>>
> On Jun 20, 2018, at 3:23 PM, Shane Kerr wrote:
>
> Ondřej,
>
> Ondřej Surý:
>> as far as I could find on the Internet there are only SIG(0) implementation
>> in handful DNS implementations - BIND, PHP Net_DNS2 PHP library,
>> Net::DNS(::Sec) Perl library, trust_dns written in Rust and
Ondřej,
Ondřej Surý:
> as far as I could find on the Internet there are only SIG(0) implementation
> in handful DNS implementations - BIND, PHP Net_DNS2 PHP library,
> Net::DNS(::Sec) Perl library, trust_dns written in Rust and perhaps others I
> haven’t found; no mentions of real deployment
On Wed, Jun 20, 2018 at 09:48:40AM +1000, Mark Andrews wrote:
> Donald Eastlake’s early DNSSEC work had a working zone signature. It doesn’t
> require signing each message. It’s just relatively expensive to compute for
> large zones as it requires hashing the entire zone.
>
> RFC 2065 4.1.3
> On Jun 19, 2018, at 4:48 PM, Ondřej Surý wrote:
>
>
> Do people think the SIG(0) is something that we should keep in DNS and it
> will be used in the future or it is a good candidate for throwing off the
> boat?
>
> Ondrej
As far as I can tell, SIG(0) is the only mechanism in DNS to
On 20.6.2018 16:10, Paul Wouters wrote:
> On Wed, 20 Jun 2018, Petr Špaček wrote:
>
>> it seems that current specification of DNS cookies in RFC 7873 is not
>> detailed enough to allow deployment of DNS cookies in multi-vendor
>> anycast setup, i.e. a setup where one IP address is backed by
You might get a kick out of this expired but soon-to-be-revived document in
DNSSD: https://tools.ietf.org/html/draft-sctl-service-registration-00
The principle is a bit different than what you're doing because there's no
DHCP (necessarily) involved, but otherwise it's the same basic idea.
On
On Wed, 20 Jun 2018, Petr Špaček wrote:
it seems that current specification of DNS cookies in RFC 7873 is not
detailed enough to allow deployment of DNS cookies in multi-vendor anycast
setup, i.e. a setup where one IP address is backed by multiple DNS servers.
The problem is lack of
tjw ietf wrote:
With all of you here.
As an Operator who gets these requests regularly (just 10 minutes
ago!) when you tell users the world of BIND/PowerDNS/NSD/Knot do not
support such a mechanism they say “we’re off to use route 53.
okthxbai “
there is a reason the spec doesn't support
Well Mark did propose this many years ago:
https://mailman.nanog.org/pipermail/nanog/2013-October/061619.html
And based on that, I created a half-assed implementation using Net::DNS.
Of course I never got around to polishing it up enough to actually put
it into production. And definitely not
Well define HTTP which is identical to SRV without the prefix.
None of this is hard to do. That’s 10 minutes work after IANA allocates the
code point.
--
Mark Andrews
On 20 Jun 2018, at 19:40, Jan Včelák wrote:
>> It's also their intransigence re: SRV which has caused the CNAME at the
>>
On 20/06/2018 10:40, Jan Včelák wrote:
> SRV also trades CNAME at apex for wildcard names support.
Yes, that's a fair point, and indeed one of the biggest issues with SRV.
Ray
___
DNSOP mailing list
DNSOP@ietf.org
> It's also their intransigence re: SRV which has caused the CNAME at the
> Apex issue. CNAME was *never* the right answer for doing application
> level indirection in HTTP space.
SRV also trades CNAME at apex for wildcard names support. There is a
plenty of services that employ wildcards to
Wellington, Brian wrote:
> SIG(0) was implemented in BIND 9 back when BIND 9 was basically the only
> modern implementation, and no one used it then.
I think the problem is it isn't a complete implementation: you can't use
SIG(0) in all the places you can use TSIG. The TKEY support seems to be
Ondřej Surý wrote:
> But is it really used like this? Or will it ever?
My point was that SIG(0) has use cases that are currently impossible
because of lack of implementations. So it's really hard to tell if it is
worth the effort. It's like trying to judge the need for a bridge by
counting the
Hello dnsop,
it seems that current specification of DNS cookies in RFC 7873 is not
detailed enough to allow deployment of DNS cookies in multi-vendor
anycast setup, i.e. a setup where one IP address is backed by multiple
DNS servers.
The problem is lack of standardized algorithm to generate
I run bind on my authoritative nameservers. I run linux on a number of
laptops. When these laptops are provided a DHCP address, they use SIG(0)
to authenticate a forwards zone update to update their current (DHCP
provided) IPv4 address into the Zone. I've been doing this for years -
ever since
25 matches
Mail list logo
