It's a viable strategy. No legitimate implementation produces compression pointers that go anywhere other than backwards. I track the start of a label sequence and whether I've followed a pointer. If I've just followed…
https://powerdns.org/hello-dns/
> On the TLSA side, the argument is roughly that (1) the WebPKI is bad ... Is that a common argument? I've seen it argued that WebPKI shouldn't be used because it outsources DNS trust to the CAB forum, but not "WebPKI…
There's private use ranges for classes and types. They don't have specific mnemonics but you can use the generic ones (eg: CLASS65280 and TYPE65280). CHAOS probably gets used most because that's what BIND happened to do.
A possibly needless clarification: The DNS is organised by class, name, and then type. Each class is a seperate space, so ycombinator.com in the IN (Internet) class and ycombinator.com in any other class aren't…
I can understand how you might arrive at such an intuition but I'm not sure how well it serves you, particularly when you apply it outside of the search results that have formed it. There's over 150 million names under…
> ... especially on a "nonstandard" TLD. I guess that's a dig but I'm not sure why. It's resolvable via the ICANN root and is no more "nonstandard" than any of its siblings.
Has anyone here had experience with Glauca? I'm curious about them because they support RFC 2136.
Namecheap's DNSSEC implementation has broken a number of times and last I looked their API was pretty poor.
My problem with this spec is it requires Service Providers and DNS Providers to know about each other. It's essentially formalising the status quo of cookie cutter setups for big name providers.
Dynamic responses make transfers difficult to implement in some server architectures. Which is not to take away from your point - trying to hide things in the DNS is a fairly pointless exercise.
IXFR is for incremental transfers in which the client asks for a series of diffs between a particular serial and the current one. AXFR requests a transfer of the full zone. dig supports supports both.
> Multiple questions inside the same packet are quite common in DNS-SD based multicast queries. mDNS is DNS in name only. Yes the wire format is mostly the same but the semantics are not. > Note that technically,…
> deactivate message compression if possible. PowerDNS tried this early on, it ended poorly because a client with a large installed base assumed that answers following the question section would start with a compression…
What was the implementation that produced the bad NSEC3 proofs?
It's a viable strategy. No legitimate implementation produces compression pointers that go anywhere other than backwards. I track the start of a label sequence and whether I've followed a pointer. If I've just followed…
https://powerdns.org/hello-dns/
> On the TLSA side, the argument is roughly that (1) the WebPKI is bad ... Is that a common argument? I've seen it argued that WebPKI shouldn't be used because it outsources DNS trust to the CAB forum, but not "WebPKI…
There's private use ranges for classes and types. They don't have specific mnemonics but you can use the generic ones (eg: CLASS65280 and TYPE65280). CHAOS probably gets used most because that's what BIND happened to do.
A possibly needless clarification: The DNS is organised by class, name, and then type. Each class is a seperate space, so ycombinator.com in the IN (Internet) class and ycombinator.com in any other class aren't…
I can understand how you might arrive at such an intuition but I'm not sure how well it serves you, particularly when you apply it outside of the search results that have formed it. There's over 150 million names under…
> ... especially on a "nonstandard" TLD. I guess that's a dig but I'm not sure why. It's resolvable via the ICANN root and is no more "nonstandard" than any of its siblings.
Has anyone here had experience with Glauca? I'm curious about them because they support RFC 2136.
Namecheap's DNSSEC implementation has broken a number of times and last I looked their API was pretty poor.
My problem with this spec is it requires Service Providers and DNS Providers to know about each other. It's essentially formalising the status quo of cookie cutter setups for big name providers.
Dynamic responses make transfers difficult to implement in some server architectures. Which is not to take away from your point - trying to hide things in the DNS is a fairly pointless exercise.
IXFR is for incremental transfers in which the client asks for a series of diffs between a particular serial and the current one. AXFR requests a transfer of the full zone. dig supports supports both.
> Multiple questions inside the same packet are quite common in DNS-SD based multicast queries. mDNS is DNS in name only. Yes the wire format is mostly the same but the semantics are not. > Note that technically,…
> deactivate message compression if possible. PowerDNS tried this early on, it ended poorly because a client with a large installed base assumed that answers following the question section would start with a compression…
What was the implementation that produced the bad NSEC3 proofs?