Hi,
.NU has for many years been signed with NSEC3. When the Swedish Internet
foundation took over .nu in 2013 we continued with NSEC3. In 2017 we started to
publish all zone files for .nu and .se (zonedata.iis.se). Since then we have
wanted to do a roll over to NSEC.
Today is that day! At 13
fujiw...@jprs.co.jp wrote:
>
> We need four types of glue names.
> Please propose new names.
I thought this was supposed to be documenting existing terminology, not
inventing new terminology.
There are two kinds of glue:
* glue required by the DNS, for in-bailiwick nameservers
* siblin
Over in the DMARC working group we have this DNS application.
If someone sends you a messsage from, say, b...@sales.east.bigcorp.com.
your mail system looks for a policy record at
_dmarc.sales.east.bigcorp.com. If it doesn't find one, it looks for
one in the "organizational domain", in this case _
John Levine wrote:
>
> It occurs to me that for DMARC's purposes, walking up the tree would
> work better than the current hack. I know it would sometimes find a
> different answer from what it gets now, which is OK. When this came up
> before, the advice was that DNS tree walks are very bad, so d
It occurs to me that for DMARC's purposes, walking up the tree would
work better than the current hack.
CAA records are perhaps less of a target for query amplification abuse
than DMARC records :-)
I dunno, seems to me the stakes are higher for CAA but the number of
requests per domain are f
if you guys are going to automate and secure the public suffix list
functionality, please spare a thought for automated / at-scale ("not
in whois") identification of the domain's registrar and registrant.
i'd like to be able to filter inbound traffic based on who paid the
money for a domain, who g
if you guys are going to automate and secure the public suffix list
functionality, ...
Not a chance.
icann will likely never require it, but hopefully ietf can specify
it, after which the invisible hand of the market can decide it.
Doubly not a chance. Having been hanging around the "expedi
On Wed, Nov 11, 2020 at 05:17:54PM -0500, John R Levine wrote:
> > if you guys are going to automate and secure the public suffix list
> > functionality, ...
>
> Not a chance.
seems like we're passing like ships in the night here.
> > icann will likely never require it, but hopefully ietf can sp
John R Levine wrote:
>
> > One possible way for DMARC to mitigate it would be to walk *down* instead
> > of up, and (in the application, not relying on the recursive server) stop
> > on NXDOMAIN because RFC 8020 tells you this is sensible, otherwise take
> > the last result you find.
>
> I wouldn'
if you guys are going to automate and secure the public suffix list
functionality, ...
Not a chance.
seems like we're passing like ships in the night here.
We had a DBOUND working group that tried and failed to do that. For
DMARC, we don't really care where the boundaries are, only if some
Paul Vixie wrote:
>
> i'd like to be able to filter inbound traffic based on who paid the
> money for a domain, who got that money, or whether either of them
> wishes to remain anonymous.
The crucial difference is that CAA/DMARC are consensual: the publisher and
the checker both want to use the p
On 11 Nov 2020, at 17:08, Paul Vixie wrote:
> if you guys are going to automate and secure the public suffix list
> functionality, please spare a thought for automated / at-scale ("not
> in whois") identification of the domain's registrar and registrant.
I understand the reason why being able to
On Wed, Nov 11, 2020 at 10:38:12PM +, Tony Finch wrote:
> Paul Vixie wrote:
> >
> > i'd like to be able to filter inbound traffic based on who paid the
> > money for a domain, who got that money, or whether either of them
> > wishes to remain anonymous.
>
> The crucial difference is that CAA/
On Wed, Nov 11, 2020 at 05:45:52PM -0500, Joe Abley wrote:
> On 11 Nov 2020, at 17:08, Paul Vixie wrote:
>
> > if you guys are going to automate and secure the public suffix list
> > functionality, please spare a thought for automated / at-scale ("not
> > in whois") identification of the domain's
14 matches
Mail list logo
